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Para Suzanne, Barbara, Marvin e à memória de Sweetie mt e Bram 
— AST 


Para Barbara e Gordon 
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O mascote do MINIX 3 


Os outros sistemas operacionais têm um animal como mascote; assim, achamos que o 
MINIX 3 também deveria ter um. Escolhemos o guaxinim porque os guaxinins são pequenos, 
simpáticos, inteligentes, ágeis, comem insetos e são amistosos — pelo menos se você manti- 
ver sua lata de lixo bem fechada. 
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Muitos livros sobre sistemas operacionais são fortes na parte teórica e fracos na parte prá- 
tica. Este, contudo, tem como objetivo proporcionar um melhor equilíbrio entre ambas as 
partes. Ele aborda cuidadosamente todos os princípios fundamentais, incluindo processos, 
comunicação entre processos, semáforos, monitores, passagem de mensagens, algoritmos 
de escalonamento, entrada/saída, impasses, drivers de dispositivo, gerenciamento de memó- 
ria, algoritmos de paginação, projeto do sistema de arquivos, segurança e mecanismos de 
proteção. Mas ele também discute em detalhes um sistema em particular — o MINIX 3 — um 
sistema operacional compatível com o UNIX, e fornece o seu código-fonte para estudo. Essa 
organização permite que o leitor não apenas aprenda os princípios, mas também veja como 
eles são aplicados em um sistema operacional real. 

Quando a primeira edição deste livro foi publicada, em 1987, causou uma pequena re- 
volução na maneira como os cursos de sistemas operacionais eram ministrados. Até então, a 
maioria dos cursos abordava apenas a teoria. Com o aparecimento do MINIX, muitos cursos 
começaram a oferecer aulas práticas nas quais os alunos examinavam um sistema operacional 
real para ver seu funcionamento interno. Consideramos essa tendência altamente desejável e 
esperamos que ela continue. 

Nos seus primeiros 10 anos, o MINIX sofreu muitas mudanças. O código original foi 
projetado para um IBM PC baseado no 8088, com 256K de memória, duas unidades de dis- 
quete e sem disco rígido. Além disso, ele era baseado na Versão 7 do UNIX. Com o tempo, o 
MINIX evoluiu de muitas maneiras, como o suporte aos processadores de 32 bits com modo 
protegido e grande capacidade de memória e de discos rígidos. Ele também mudou da antiga 
origem da Versão 7, para basear-se no padrão internacional POSIX (IEEE 1003.1 e ISO 9945- 
1). Finalmente, muitos recursos novos foram acrescentados, talvez demais, no nosso modo de 
ver, mas poucos, na visão de algumas outras pessoas, que levaram à criação do Linux. Além 
disso, o MINIX foi portado para muitas outras plataformas, incluindo Macintosh, Amiga, 
Atari e SPARC. Uma segunda edição deste livro foi publicada em 1997 e foi amplamente 
usada em universidades. 

A popularidade do MINIX continuou, conforme pode ser observado examinando-se o 
número de respostas encontradas no Google para MINIX. 

Esta terceira edição do livro tem muitas alterações por toda parte. Praticamente todo o 
material sobre princípios foi revisado e um volume considerável de material novo foi adicio- 
nado. Entretanto, a principal mudança é a discussão sobre a nova versão do sistema, chamado 
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de MINIX 3, e a inclusão do novo código neste livro. Embora seja vagamente baseado no 
MINIX 2, o MINIX 3 é fundamentalmente diferente sob muitos aspectos importantes. 

O projeto do MINIX 3 foi inspirado pela observação de que os sistemas operacionais 
estão se tornando enormes, lentos e pouco confiáveis. Eles falham com muito mais freqüência 
do que outros equipamentos eletrônicos, como televisões, telefones celulares e DVDs, e têm 
tantos recursos e opções que praticamente ninguém consegue entendê-los completamente 
nem gerenciá-los bem. E, é claro, os vírus de computador, os vermes, os spywares, os spams 
e outras formas de códigos maliciosos (malware) têm se tornado epidemias. 

De modo geral, muitos desses problemas são causados por uma falha de projeto funda- 
mental nos sistemas operacionais atuais: sua falta de modularidade. O sistema operacional 
inteiro normalmente tem milhões de linhas de código em C/C++, compilado em um único 
programa executável enorme, executado no modo núcleo. Um erro em qualquer uma dessas 
milhões de linhas de código pode fazer o sistema deixar de funcionar. É impossível que todo 
esse código esteja correto, especialmente quando cerca de 70% dele consiste em drivers de 
dispositivos, escrito por terceiros e fora do controle das pessoas que mantêm o sistema ope- 
racional. 

Com o MINIX 3, demonstramos que esse projeto monolítico não é a única possibili- 
dade. O núcleo do MINIX 3 tem apenas cerca de 4000 linhas de código executável e não as 
milhões de linhas encontradas no Windows, no Linux, no Mac OS X ou no FreeBSD. O resto 
do sistema, incluindo todos os drivers de dispositivos (exceto o driver de relógio), é um con- 
junto de pequenos processos modulares em modo usuário, cada um dos quais rigorosamente 
restritos quanto ao que pode fazer e com quais outros processos pode se comunicar. 

Embora o MINIX 3 seja um trabalho em andamento, acreditamos que esse modelo de 
construção de sistema operacional, com um conjunto de processos em modo usuário altamen- 
te encapsulados, tem a capacidade de promover a construção de sistemas mais confiáveis no 
futuro. O MINIX 3 é particularmente voltado aos PCs de menor capacidade (como aqueles 
normalmente encontrados nos países do Terceiro Mundo e em sistemas embarcados, que são 
sempre restritos quanto aos recursos). De qualquer maneira, este projeto torna muito mais 
fácil para os alunos aprenderem como um sistema operacional funciona, do que tentar estudar 
um sistema monolítico enorme. 

O CD-ROM incluído neste livro é um CD-live, isto é, você pode colocá-lo em sua uni- 
dade de CD-ROM, reinicializar o computador e o MINIX 3 fornecerá um prompt de login 
dentro de poucos segundos. Você pode conectar-se como root e experimentar o sistema, sem 
primeiro ter de instalá-lo em seu disco rígido. Naturalmente, ele também pode ser instalado 
no disco rígido. Instruções detalhadas para a instalação são dadas no Apêndice A. 

Conforme dito anteriormente, o MINIX 3 está evoluindo rapidamente, com novas ver- 
sões sendo lançadas fregiientemente. Para fazer o download do arquivo da imagem mais atual 
para gravar em um CD-ROM, vá até o site web oficial: www.minix3.org. Esse site também 
contém uma grande quantidade de software novo, documentação e novidades sobre o desen- 
volvimento do MINIX 3. Para discussões sobre o MINIX 3, ou para fazer perguntas, existe 
um newsgroup na USENET: comp.os.minix. As pessoas que não tenham newsreaders po- 
dem acompanhar as discussões na web, no endereço http://groups.google.com/group/comp. 
os.minix. 

Como uma alternativa para instalar o MINIX 3 em seu disco rígido, é possível executá- 
lo em qualquer um dos vários simuladores de PC disponíveis atualmente. Alguns deles estão 
listados na página principal do site web. 

Os instrutores que empregam este livro como livro-texto em seus cursos universitários 
podem obter as soluções dos problemas através do representante local da Prentice Hall. O 
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livro tem seu próprio site web. Ele pode ser encontrado no endereço www.prenhall.com/ta- 
nenbaum e selecionando este título. 

Fomos extremamente felizes por ter a ajuda de muitas pessoas durante o curso deste 
projeto. Antes de tudo, Ben Gras e Jorrit Herder fizeram a maior parte da programação da 
nova versão. Eles fizeram um trabalho excelente, sob restrições de tempo apertadas, incluin- 
do responder e-mails de madrugada, em muitas ocasiões. Eles também leram o manuscrito e 
teceram muitos comentários úteis. Nosso mais profundo agradecimento aos dois. 

Kees Bot também ajudou muito nas versões anteriores, dando-nos uma boa base para 
trabalhar. Kees escreveu grande parte de trechos de código para as versões até a 2.0.4, corri- 
giu erros e respondeu numerosas perguntas. Philip Homburg escreveu a maior parte do códi- 
go de interconexão em rede, assim como ajudou de várias outras maneiras, especialmente ao 
dar um parecer detalhado sobre o manuscrito. 

Um grande número de pessoas, demais para listar, contribuiu com o código das primei- 
ras versões, ajudando a fazer o MINIX surgir. Houve tantas delas, e suas contribuições foram 
tão variadas, que não podemos nem mesmo começar a listá-las aqui; portanto, o melhor que 
podemos fazer é agradecer a todos de modo geral. 

Várias pessoas leram partes do manuscrito e deram sugestões. Gostaríamos de agrade- 
cer especialmente a ajuda de Gojko Babic, Michael Crowley, Joseph M. Kizza, Sam Kohn 
Alexander Manov e Du Zhang. 

Finalmente, gostaríamos de agradecer às nossas famílias. Suzanne já passou por isso 
dezesseis vezes. Barbara, quinze vezes. Marvin, catorze vezes. Isso está se tornando uma 
rotina, mas o amor e o apoio ainda são muito estimados. (AST) 

Quanto à Barbara (do Al), ela já passou por isso duas vezes. Seu apoio, sua paciência e 
seu bom humor foram fundamentais. Gordon foi um ouvinte paciente. Ainda é uma delícia ter 
um filho que entende e se preocupa com as coisas que me fascinam. Finalmente, o primeiro 
aniversário do meio-neto Zain coincide com o lançamento do MINIX 3. Algum dia ele vai 
gostar disso. (ASW) 

Andrew S. Tanenbaum 
Albert S. Woodhull 
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INTRODUÇÃO 


Sem software, um computador é basicamente um monte inútil de metal. Com software, um 
computador pode armazenar, processar e recuperar informações, tocar música e reproduzir 
vídeos, enviar e-mail, pesquisar a Internet e se envolver em muitas outras atividades valiosas 
para merecer sua manutenção. Grosso modo, o software de computador pode ser dividido em 
dois tipos: programas de sistema, que gerenciam a operação do computador em si, e progra- 
mas aplicativos, que realizam o trabalho real desejado pelo usuário. O programa de sistema 
mais básico é o sistema operacional, cuja tarefa é controlar todos os recursos do computador 
e fornecer uma base sobre a qual os programas aplicativos podem ser escritos. Os sistemas 
operacionais são o assunto deste livro. Em particular, um sistema operacional chamado MI- 
NIX 3 é usado como modelo para ilustrar os princípios de projeto e aspectos reais de sua 
implementação. 

Um sistema de computação moderno consiste em um ou mais processadores, memória 
principal, discos, impressoras, teclado, tela, interfaces de rede e outros dispositivos de en- 
trada/saída. No todo, um sistema complexo. Escrever programas que controlam todos esses 
componentes e os utilizam corretamente, sem dizer de forma otimizada, é uma tarefa extre- 
mamente difícil. Se todo programador tivesse que se preocupar com o funcionamento das 
unidades de disco e com todas as dezenas de coisas que poderiam dar errado ao ler um bloco 
de disco, é provável que muitos programas sequer pudessem ser escritos. Há muito tempo, 
tornou-se bastante evidente a necessidade de encontrar uma maneira de isolar os programa- 
dores da complexidade do hardware. A maneira que evoluiu gradualmente foi colocar uma 
camada de software sobre o do hardware básico, para gerenciar todas as partes do sistema e 
apresentar ao usuário uma interface, ou máquina virtual, mais fácil de entender e programar. 
Essa camada de software é o sistema operacional. 

A posição do sistema operacional aparece na Figura 1-1. Na parte inferior está o har- 
dware, o qual, em muitos casos, é composto de dois ou mais níveis (ou camadas). O nível 
mais baixo contém dispositivos físicos, sendo constituído por circuitos integrados, cabos, 
fontes de alimentação, tubos de raios catódicos e dispositivos físicos. O modo como esses 
componentes são construídos e funcionam é da competência do engenheiro elétrico. 

Em seguida, vem o nível da microarquitetura, no qual os dispositivos físicos são agru- 
pados para formar unidades funcionais. Normalmente, esse nível contém alguns registradores 
internos da UCP (Unidade Central de Processamento, ou CPU — Central Processing Unit) e 
um caminho de dados, contendo uma unidade lógica e aritmética. Em cada ciclo de relógio, 
um ou mais operandos são lidos de registradores e combinados na unidade aritmética e lógica 
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Figura 1-1 Um sistema de computação consiste em hardware, programas de sistema e pro- 
gramas aplicativos. 


(por exemplo, pela adição ou pela operação booleana E). O resultado é armazenado em um 
ou mais registradores. Em algumas máquinas, a operação do caminho de dados é controlada 
pelo software, chamado de microprograma. Em outras máquinas, ela é feita diretamente 
pelos circuitos de hardware. 

O objetivo do caminho de dados é executar algum conjunto de instruções. Algumas 
delas podem ser executadas em um ciclo de caminho de dados; outras podem exigir vários 
ciclos. Essas instruções podem usar registradores ou outros recursos de hardware. Juntos, 
o hardware e as instruções visíveis para um programador de linguagem assembly formam 
o ISA (Instruction Set Architecture — arquitetura do conjunto de instruções). Esse nível é 
frequentemente chamado de linguagem de máquina. 

Normalmente, a linguagem de máquina tem entre 50 e 300 instruções, principalmente 
para mover dados, efetuar operações aritméticas e comparar valores. Nesse nível, os dispo- 
sitivos de entrada/saída são controlados por meio da escrita de valores em registradores de 
dispositivos especiais. Por exemplo, um disco pode ser instruído a fazer uma leitura por meio 
da escrita dos valores do endereço do disco, do endereço da memória principal, da quantidade 
de bytes e da direção (leitura ou gravação) em seus registradores. Na prática, são necessários 
muito mais parâmetros, e o status retornado pela unidade de disco após uma operação pode 
ser complexo. Além disso, para muitos dispositivos de E/S (Entrada/Saída), a temporização 
desempenha um papel importante na programação. 

Uma função importante do sistema operacional é ocultar toda essa complexidade e 
fornecer um conjunto de instruções mais conveniente para o programador trabalhar. Por 
exemplo, uma instrução ler bloco do arquivo é conceitualmente muito mais simples do que 
ter de se preocupar com os detalhes da movimentação dos cabeçotes de disco, esperar que 
eles fiquem na posição correta etc. Sobre o sistema operacional está o restante do software 
de sistema. Aqui, encontramos o interpretador de comandos (shell), os sistemas de janela, 
compiladores, editores e programas independentes de aplicativos. É importante perceber que 
esses programas não fazem parte do sistema operacional, mesmo sendo normalmente forne- 
cidos previamente instalados pelo fabricante do computador, ou em um pacote com o siste- 
ma operacional, caso sejam instalados após a aquisição. Esse é um ponto fundamental, mas 
sutil. O sistema operacional é (normalmente) aquela parte do software executada em modo 
núcleo ou em modo de supervisor. Ele é protegido pelo hardware contra adulterações por 
parte do usuário (ignorando, por enquanto, alguns microprocessadores mais antigos, ou de 
menor capacidade, que não possuem nenhuma proteção de hardware). Os compiladores e 
editores são executados no modo usuário. Se um usuário não gosta de um compilador em 
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particular, ele está livre para escrever seu próprio compilador, se preferir; mas não está livre 
para escrever sua própria rotina de interrupção de relógio, que faz parte do sistema opera- 
cional e é normalmente protegida pelo hardware contra tentativas de modificação por parte 
dos usuários. 

Essa distinção, entretanto, às vezes não é clara nos sistemas embarcados (os quais podem 
não ter modo núcleo) ou nos sistemas interpretados (como os sistemas baseados em Java, que 
usam um interpretador em software e não o hardware para isolar os componentes). Contudo, 
para computadores tradicionais, o sistema operacional é o que executa no modo núcleo. 

Dito isso, em muitos sistemas existem programas que são executados no modo usuário, 
mas que ajudam o sistema operacional ou desempenham funções privilegiadas. Por exemplo, 
fregiientemente existe um programa que permite aos usuários mudarem suas senhas. Esse 
programa não faz parte do sistema operacional e não é executado no modo núcleo, mas clara- 
mente executa uma função sigilosa e precisa ser protegido de uma maneira especial. 

Em alguns sistemas, incluindo o MINIX 3, essa idéia é levada ao extremo, e parte do 
que é tradicionalmente considerado como sendo o sistema operacional (como o sistema de ar- 
quivos) é executado em modo usuário (também dito em espaço de usuário) . Em tais sistemas 
é difícil traçar um limite claro. Tudo que é executado no modo núcleo claramente faz parte 
do sistema operacional, mas é razoável considerar que alguns programas que são executados 
fora dele também fazem parte dele ou, pelo menos, estão intimamente associados a ele. Por 
exemplo, no MINIX 3, o sistema de arquivos é simplesmente um programa C enorme, exe- 
cutado em modo usuário. 

Finalmente, acima dos programas de sistema aparecem os programas aplicativos. Esses 
programas são adquiridos, ou escritos pelos usuários, para resolver seus problemas particula- 
res, como processamento de textos, planilhas eletrônicas, cálculos de engenharia ou armaze- 
namento de informações em um banco de dados. 


O QUE É O SISTEMA OPERACIONAL? 


A maioria dos usuários de computador já teve alguma experiência com um sistema operacio- 
nal, mas é difícil definir precisamente o que é um sistema operacional. Parte do problema é 
que os sistemas operacionais executam duas funções basicamente não relacionadas, amplian- 
do os recursos da máquina e de gerenciamento, e dependendo de quem está falando, você 
ouve mais sobre uma ou outra função. Vamos examinar as duas agora. 


O sistema operacional como uma máquina estendida 


Conforme mencionado anteriormente, a arquitetura (conjunto de instruções, organização 
da memória, E/S e estrutura do barramento) da maioria dos computadores em nível de lin- 
guagem de máquina é primitiva e inconveniente para programar, especialmente quanto à E/S. 
Para tornar esse ponto mais concreto, vamos ver brevemente como é feita a E/S de um disco 
flexível usando os controladores de dispositivos compatíveis com o NEC PD765, usados em 
muitos computadores pessoais baseados em Intel. (Neste livro, usaremos os termos “disco 
flexível” e “disquete” indistintamente.) O PD765 tem 16 comandos, cada um deles especifi- 
cado através da escrita entre 1 e 9 bytes em um registrador de dispositivo. Esses comandos 
servem para ler e gravar dados, mover o braço do disco, formatar trilhas, assim como para 
inicializar, monitorar, reconfigurar e recalibrar o controlador e as unidades de disco. 

Os comandos mais básicos são read e write, cada um deles exigindo 13 parâmetros, 
empacotados em 9 bytes. Esses parâmetros especificam itens como o endereço do bloco de 
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disco a ser lido, o número de setores por trilha, o modo de gravação usado na mídia física, 
o espaçamento do intervalo entre setores (interleaving) e o que fazer com uma marca de 
endereço de dados excluídos. Se você não entendeu nada desse discurso, não se preocupe; 
é essa exatamente a questão — tudo é muito esotérico. Quando a operação está terminada, o 
controlador retorna 23 campos de status e de erro, empacotados em 7 bytes. Como se não bas- 
tasse, o programa do disquete também precisa saber constantemente se o motor está ligado ou 
desligado. Se o motor estiver desligado, deverá ser ligado (com uma longa demora para sua 
inicialização) antes que os dados possam ser lidos ou escritos. Entretanto, o motor não pode 
ficar ligado por muito tempo, senão o disquete irá desgastar-se. Assim, o programa é obrigado 
a tratar do compromisso entre longos atrasos na inicialização e o desgaste dos disquetes (e a 
perda dos dados neles contidos). 

Sem entrar nos detalhes reais, deve estar claro que um programador médio provavel- 
mente não desejará se envolver intimamente com a programação de disquetes (ou de discos 
rígidos, que são igualmente complexos e bastante diferentes). Em vez disso, o programador 
deseja tratar com uma abstração simples e de alto nível. No caso dos discos, uma abstração 
típica seria o disco conter um conjunto de arquivos nomeados. Cada arquivo pode ser aberto 
para leitura ou escrita, em seguida lido ou escrito e finalmente fechado. Detalhes como se a 
escrita deve ou não usar modulação em fregiiência e qual é o estado atual do motor não de- 
vem aparecer na abstração apresentada ao usuário (programador). 

Naturalmente, o programa que oculta do usuário a realidade sobre o hardware e apre- 
senta uma visão bela e simples de arquivos nomeados que podem ser lidos e escritos é o 
sistema operacional. Assim como o sistema operacional isola o usuário do hardware do disco 
e apresenta uma interface simples orientada para arquivos, também oculta muitos detalhes 
desagradáveis relativos a interrupções, temporizadores, gerenciamento de memória e outros 
recursos de mais baixo nível. Em cada caso, a abstração oferecida pelo sistema operacional é 
mais simples e mais fácil de usar do que aquela oferecida pelo hardware subjacente. 

Sob esse ponto de vista, a função do sistema operacional é apresentar ao usuário o 
equivalente a uma máquina estendida, ou máquina virtual, mais fácil de programar do 
que o hardware que a compõe. O modo como o sistema operacional atinge esse objetivo é 
uma longa história, que estudaremos em detalhes por todo este livro. Para resumir em poucas 
palavras, o sistema operacional fornece uma variedade de serviços que os programas podem 
obter usando instruções especiais denominadas chamadas de sistema. Posteriormente, neste 
capítulo, examinaremos algumas das chamadas de sistema mais comuns. 


O sistema operacional como gerenciador de recursos 


O conceito do sistema operacional como fornecendo principalmente uma interface conve- 
niente para seus usuários é uma visão top-down (de cima para baixo). Uma visão alternativa, 
botton-up (de baixo para cima), sustenta que o sistema operacional existe para gerenciar 
todas as partes de um sistema complexo. Os computadores modernos são compostos de pro- 
cessadores, memórias, temporizadores, discos, mouses, interfaces de rede, impressoras e uma 
ampla variedade de outros dispositivos. Na visão alternativa, a tarefa do sistema operacional é 
fornecer uma alocação ordenada e controlada dos processadores, memórias e dispositivos de 
E/S entre os vários programas que concorrem por eles. 

Imagine o que aconteceria se três programas sendo executados em um computador 
tentassem todos imprimir suas saídas simultaneamente na mesma impressora. As primeiras 
linhas da saída impressa poderiam ser do programa 1, as linhas seguintes do programa 2 
e, então, algumas do programa 3 etc. O resultado seria o caos. O sistema operacional pode 
trazer ordem ao caos em potencial, armazenando no disco, por programa, toda a saída desti- 
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nada à impressora. Quando um programa tiver terminado, o sistema operacional envia para 
a impressora a sua saída armazenada no arquivo em disco, enquanto, ao mesmo tempo, um 
outro programa poderá continuar gerando mais saída, ignorando o fato de que ela não está 
realmente indo para a impressora (ainda). 

Quando um computador (ou uma rede) tem vários usuários, a necessidade de gerenciar 
e proteger a memória, dispositivos de E/S e outros recursos é ainda maior, pois os usuá- 
rios poderiam interferir uns com os outros. Além disso, os usuários frequentemente precisam 
compartilhar não apenas o hardware, mas também informações (arquivos, bancos de dados 
etc.). Em resumo, essa visão do sistema operacional sustenta que sua principal tarefa é con- 
trolar quem está usando qual recurso, garantir os pedidos de recursos, medir a utilização e 
mediar pedidos conflitantes de diferentes programas e usuários. 

O gerenciamento de recursos inclui a multiplexação (compartilhamento) de recursos de 
duas maneiras: no tempo e no espaço. Quando um recurso é multiplexado no tempo, diferen- 
tes programas ou usuários o utilizam por turnos: primeiro um deles utiliza o recurso, depois 
outro e assim por diante. Por exemplo, com apenas uma CPU e vários programas que queiram 
ser executados nela, o sistema operacional primeiramente aloca a CPU para um programa 
e, depois, após o programa ter executado o suficiente, outro programa utiliza a CPU, depois 
outro e, finalmente, o primeiro programa novamente. Determinar como o recurso é multiple- 
xado no tempo — quem vem em seguida e por quanto tempo — é tarefa do sistema operacional. 
Outro exemplo de multiplexação no tempo é o compartilhamento da impressora. Quando 
várias tarefas de impressão são enfileiradas em uma única impressora, uma decisão precisa 
ser tomada com relação a qual das tarefas deve ser impressa a seguir. 

O outro tipo de multiplexação é a no espaço. Em vez dos clientes atuarem por turnos, 
cada um deles recebe parte do recurso. Por exemplo, normalmente, a memória principal 
é dividida entre vários programas que estejam em execução para que cada um possa estar 
residente ao mesmo tempo (por exemplo, para utilizar a CPU por turnos). Supondo que haja 
memória suficiente para conter múltiplos programas, é mais eficiente manter vários progra- 
mas na memória de uma vez do que alocar toda ela para um único programa, especialmente 
se ele precisar apenas de uma pequena fração do total. É claro que isso levanta problemas 
de imparcialidade, proteção etc., e fica por conta do sistema operacional resolvê-los. Outro 
recurso multiplexado no espaço é o disco (rígido). Em muitos sistemas, um único disco pode 
conter arquivos de muitos usuários ao mesmo tempo. Alocar espaço em disco e controlar 
quem está usando quais blocos de disco é uma típica tarefa de gerenciamento de recursos do 
sistema operacional. 


HISTÓRIA DOS SISTEMAS OPERACIONAIS 


Os sistemas operacionais vêm evoluindo ao longo dos anos. Nas seções a seguir, veremos re- 
sumidamente alguns dos destaques. Como, historicamente, os sistemas operacionais têm sido 
intimamente ligados à arquitetura dos computadores em que são executados, examinaremos 
as sucessivas gerações de computadores para vermos como eram seus sistemas operacionais. 
Esse mapeamento das gerações de sistema operacional para gerações de computador é gros- 
seiro, mas oferece uma base que de outra forma não teríamos. 

O primeiro computador digital foi projetado pelo matemático inglês Charles Babbage 
(1792-1871). Embora Babbage tenha gasto a maior parte de sua vida e de sua fortuna tentan- 
do construir sua “máquina analítica”, nunca conseguiu fazê-la funcionar corretamente, pois 
ela era puramente mecânica e a tecnologia de seu tempo não podia produzir as rodas e en- 
grenagens exigidas com a alta precisão que necessitava. É desnecessário dizer que a máquina 
analítica não tinha sistema operacional. 
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Como um dado histórico interessante, Babbage percebeu que precisaria de software 
para sua máquina analítica, assim, contratou como a primeira programadora do mundo, uma 
jovem chamada Ada Lovelace, que era filha do famoso poeta britânico Lord Byron. A lingua- 
gem de programação Ada” recebeu esse nome em sua homenagem. 


A primeira geração (1945-1955): válvulas e painéis de conectores 


Depois dos esforços mal-sucedidos de Babbage, pouco progresso foi feito na construção 
de computadores digitais até a II Guerra Mundial. Em meados da década de 40, Howard 
Aiken, da Universidade de Harvard, John von Neumann, do Instituto de Estudos Avan- 
çados de Princeton, J. Presper Eckert e John Mauchley, da Universidade da Pensilvânia, 
e Konrad Zuse, na Alemanha, entre outros, tiveram êxito na construção de máquinas de 
calcular. As primeiras delas usavam relés mecânicos, mas eram muito lentas, com tempos 
de ciclo medidos em segundos. Posteriormente, os relés foram substituídos por válvulas a 
vácuo. Essas máquinas eram enormes, ocupavam salas inteiras com dezenas de milhares 
de válvulas, mas ainda eram milhões de vezes mais lentas do que os computadores pes- 
soais mais baratos de hoje. 

Naqueles tempos, um único grupo de pessoas projetava, construía, programava, opera- 
va e mantinha cada máquina. Toda a programação era feita em linguagem de máquina pura, 
fregiientemente interligando fios através de painéis de conectores para controlar as funções 
básicas da máquina. As linguagens de programação não existiam (nem mesmo a linguagem 
assembly). Ninguém tinha ouvido falar de sistemas operacionais. O modo de operação normal 
era o programador reservar um período de tempo em uma folha de reserva afixada na parede, 
depois descer à sala da máquina, inserir seu painel de conectores no computador e passar as 
próximas horas esperando que nenhuma das quase 20.000 válvulas queimasse durante a exe- 
cução. Praticamente todos os problemas resolvidos eram cálculos numéricos simples, como a 
geração de tabelas de senos, co-senos e logaritmos. 

No início da década de 50, a rotina havia melhorado um pouco, com a introdução dos 
cartões perfurados. Agora era possível, em vez de usar painéis de conectores, escrever progra- 
mas em cartões de papel e lê-los; fora isso, o procedimento era o mesmo. 


A segunda geração (1955-1965): transistores e sistemas de lote 


A introdução do transistor, em meados da década de 50, mudou o quadro radicalmente. Os 
computadores se tornaram confiáveis o bastante para serem fabricados e vendidos para clien- 
tes com a expectativa de que continuariam a funcionar por tempo suficiente para realizarem 
algum trabalho útil. Pela primeira vez, havia uma separação clara entre projetistas, construto- 
res, operadores, programadores e pessoal de manutenção. 

Essas máquinas, agora chamadas de computadores de grande porte (ou mainframes), 
eram postas em salas especiais com ar-condicionado e com equipes de operadores profissio- 
nais especialmente treinadas para mantê-las funcionando. Somente grandes empresas, impor- 
tantes órgãos do governo ou universidades podiam arcar com seu preço, na casa dos milhões 
de dólares. Para executar um job (tarefa), isto é, um programa ou um conjunto de programas, 
um programador primeiro escrevia o programa no papel (em FORTRAN ou possivelmente 
até em linguagem assembly) e depois o transformava em cartões perfurados. Então, ele leva- 
va a pilha de cartões para a sala de submissão de jobs, o entregava para um dos operadores 
e ia tomar café até que a saída estivesse pronta. Quando o computador terminava o job que 
estava executando, um operador ia até a impressora, destacava a saída impressa e a levava 
para uma sala de saída, para que o programador pudesse pegá-la posteriormente. Então, o 
operador pegava uma das pilhas de cartões que tinham sido trazidas para a sala de submissão 
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e os inseria na máquina de leitura. Se o compilador FORTRAN fosse necessário, o operador 
teria que pegá-lo em um gabinete de arquivos e inseri-lo para leitura. Enquanto os operadores 
andavam pelas salas da máquina, de submissão e de saída, o computador ficava ocioso. Dado 
o alto custo do equipamento, não é de surpreender que as pessoas procurassem rapidamente 
maneiras de reduzir o tempo desperdiçado. A solução geralmente adotada era o sistema de 
processamento em lotes (batch system). A idéia era reunir em uma bandeja (tray) um con- 
junto de jobs da sala de submissão e então lê-los em uma fita magnética usando um compu- 
tador relativamente pequeno e barato, como o IBM 1401, que era muito bom para ler cartões, 
copiar fitas e imprimir a saída, mas péssimo para cálculos numéricos. Outras máquinas muito 
mais caras, como o IBM 7094, eram usadas para a computação de fato. Essa situação aparece 
na Figura 1-2. 


Unidade . Fita de 
de fita Fita de sistema Fita de 


Leitora de 
cartões 
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7094 1401 


(a) (b) (c) (a) (e) (b) 


Figura 1-2 Um sistema de processamento em lotes primitivo. (a) Os programadores trazem 
os cartões para o 1401. (b) O 1401 lê o lote de jobs na fita. (c) O operador leva a fita de en- 
trada para o 7094. (d) O 7094 realiza a computação. (e) O operador leva a fita de saída para o 
1401. (f) O 1401 imprime a saída. 


Após cerca de uma hora de leitura de lotes de jobs, a fita era rebobinada e levada para 
a sala da máquina, onde era montada em uma unidade de fita. O operador carregava então 
um programa especial (o ancestral do sistema operacional de hoje), que lia o primeiro job da 
fita e a executava. A saída era gravada em uma segunda fita, em vez de ser impressa. Depois 
que cada job terminava, o sistema operacional lia automaticamente o próximo job da fita e 
começava a executá-lo. Quando o lote inteiro estava pronto, o operador removia as fitas de 
entrada e saída, substituía a fita de entrada pelo próximo lote e levava a fita de saída para um 
1401 imprimir off line (isto é, não conectado ao computador principal). 

A estrutura típica de um job aparece na Figura 1-3. Ele começava com um cartão 
$JOB, especificando o tempo de execução máximo, em minutos, o número da conta a ser 
cobrada e o nome do programador. Em seguida, vinha um cartão SFORTRAN, instruindo o 
sistema operacional a carregar o compilador FORTRAN da fita de sistema. Depois, vinha o 
programa a ser compilado e, então, um cartão $LOAD, orientando o sistema operacional a 
carregar o programa-objeto recém compilado. (Frequentemente, os programas compilados 
eram gravados em fitas virgens e tinham de ser carregados explicitamente.) Em seguida, 
vinha o cartão $RUN, instruindo o sistema operacional a executar o programa com os dados 
que o seguiam. Finalmente, o cartão SEND marcava o fim do job. Esses cartões de controle 
primitivos foram os precursores das linguagens de controle de jobs modernos e dos interpre- 
tadores de comandos. 

Grandes computadores de segunda geração eram usados principalmente para cálcu- 
los científicos e de engenharia, como a solução de equações diferenciais parciais que fre- 
quentemente ocorrem na física e na engenharia. Eles eram programados principalmente em 
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FORTRAN e em linguagem assembly. Sistemas operacionais típicos eram o FMS (o Fortran 
Monitor System) e o IBSYS, sistema operacional da IBM para o 7094. 


$JOB, 10,6610802, MARVIN TANENBAUM 


Figura 1-3 Estrutura típica de um job FMS. 


A terceira geração (1965-1980): Cis e multiprogramação 


No início da década de 60, a maioria dos fabricantes de computadores tinha duas linhas de 
produtos distintas e totalmente incompatíveis. Por um lado, havia os computadores científicos 
de grande escala, baseados em palavras binárias, como o 7094, que eram utilizados para cál- 
culos numéricos em ciência e engenharia. Por outro, havia os computadores comerciais, ba- 
seados em caracteres, como o 1401, que eram amplamente usados por bancos e companhias 
de seguro para ordenar e imprimir fitas. 

Desenvolver, manter e comercializar duas linhas de produtos completamente diferen- 
tes era uma proposta cara para os fabricantes de computadores. Além disso, muitos clientes 
novos necessitavam, inicialmente, de uma máquina pequena, mas posteriormente cresciam e 
queriam uma máquina maior, que tivesse a mesma arquitetura da atual para poderem executar 
todos os seus programas antigos, só que mais rapidamente. 

A IBM tentou resolver esses dois problemas de uma só vez introduzindo o System/360. 
O 360 era uma série de máquinas de software compatível que variavam desde a capacidade de 
um 1401 até um muito mais poderoso do que o 7094. As máquinas diferiam apenas no preço 
e no desempenho (capacidade máxima de memória, velocidade do processador, número de 
dispositivos de E/S permitidos etc.). Como todas as máquinas tinham a mesma arquitetura 
e o mesmo conjunto de instruções, os programas escritos para uma podiam ser executados 
em todas as outras, pelo menos teoricamente. Além disso, o 360 foi projetado para realizar 
computação científica (isto é, numérica) e comercial. Assim, uma única família de máquinas 
podia satisfazer as necessidades de todos os clientes. Nos anos seguintes, a IBM lançou novos 
produtos sucessores usando tecnologia mais moderna, compatíveis com a linha 360, conheci- 
dos como as séries 370, 4300, 3080, 3090 e Z. 

O 360 foi a primeira linha de computadores importante a usar circuitos integrados 
(CIs), oferecendo assim uma importante vantagem de preço/desempenho em relação às má- 
quinas de segunda geração, que eram construídas a partir de transistores individuais. Ele 
teve sucesso imediato e a idéia de uma família de computadores compatíveis logo foi ado- 
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tada por todos os outros principais fabricantes. As descendentes dessas máquinas ainda são 
empregadas nos centros de computação atuais. Hoje em dia, elas são frequentemente usadas 
para gerenciamento de bancos de dados grandes (por exemplo, para sistemas de reservas 
de passagens aéreas) ou como servidores de sites web que precisam processar milhares de 
pedidos por segundo. 

A maior força da idéia de “uma família” foi ao mesmo tempo sua maior fraqueza. A 
intenção era que todo software, incluindo o sistema operacional, o 08S/360, funcionasse em 
todos os modelos. Ele tinha que funcionar em sistemas pequenos, que frequentemente apenas 
substituíam os 1401 para copiar cartões em fita, e em sistemas muito grandes, que muitas ve- 
zes substituíam os 7094 para fazer previsão do tempo e outros cálculos pesados. Ele tinha que 
ser bom em sistemas com poucos periféricos e em sistemas com muitos periféricos. Tinha 
que funcionar em ambientes comerciais e em ambientes científicos. Acima de tudo, ele tinha 
que ser eficiente em todos esses diferentes usos. 

Não havia como a IBM (ou quem quer que fosse) escrever um software para atender a 
todos esses requisitos conflitantes. O resultado foi um sistema operacional enorme e extraor- 
dinariamente complexo, provavelmente duas ou três vezes maior do que o FMS. Ele consistia 
em milhões de linhas de linguagem assembly, escritas por milhares de programadores, e con- 
tinha milhares e milhares de erros, que necessitavam um fluxo contínuo de novas versões na 
tentativa de corrigi-los. Cada nova versão corrigia alguns erros e introduzia outros, de modo 
que o número de erros provavelmente permanecia constante com o tempo. 

Posteriormente, um dos projetistas do 0S/360, Fred Brooks, escreveu um livro espiri- 
tuoso e incisivo descrevendo suas experiências com o 08/360 (Brooks, 1995). Embora seja 
impossível resumir o livro aqui, basta dizer que a capa mostra uma manada de animais pré- 
históricos atolados em uma vala de alcatrão. A capa do livro de Silberschatz et al. (2004) faz 
uma comparação semelhante, sobre o fato de os sistemas operacionais serem dinossauros. 

Apesar de seu tamanho enorme e de seus problemas, o OS/360 e os sistemas operacio- 
nais de terceira geração semelhantes, produzidos por outros fabricantes de computadores, sa- 
tisfizeram a maioria de seus clientes razoavelmente bem. Eles também popularizaram várias 
técnicas importantes, ausentes nos sistemas operacionais de segunda geração. Provavelmente 
a mais importante delas foi a multiprogramação. No 7094, quando o job corrente fazia uma 
pausa para esperar a conclusão de uma operação de fita, ou de outro dispositivo de E/S, a CPU 
simplesmente ficava ociosa até que a operação terminasse. No caso de cálculos científicos, 
que exigem muito da CPU, as operações de E/S não são freqüentes, de modo que esse tempo 
desperdiçado não é significativo. No caso do processamento de dados comerciais, o tempo de 
espera pelas operações de E/S frequentemente chegava a 80 ou 90 porcento do tempo total; 
portanto, algo tinha que ser feito para evitar que a CPU (cara) ficasse tão ociosa. 

A solução desenvolvida foi dividir a memória em várias partições, com um job diferente 
em cada partição, como mostra a Figura 1-4. Enquanto um job estava esperando a conclusão 
da operação de E/S, outro podia usar a CPU. Se jobs suficientes pudessem ser mantidos si- 
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Figura 1-4 Um sistema de multiprogramação com três jobs na memória. 
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multaneamente na memória principal, a CPU poderia ficar ocupada praticamente 100% do 
tempo. Manter vários jobs simultâneos, com segurança, em memória, exige hardware espe- 
cial para proteger cada um deles, evitando que um interfira e cause danos no outro, mas o 360 
e outros sistemas de terceira geração estavam equipados com esse hardware. 

Outro recurso importante apresentado nos sistemas operacionais de terceira geração 
foi a capacidade de ler jobs de cartões para o disco assim que eram trazidos para a sala do 
computador. Então, quando um job em execução acabava, o sistema operacional podia car- 
regar um novo job do disco na partição, agora vazia, e executá-lo. Essa técnica é chamada de 
spooling (de Simultaneous Peripheral Operation On Line — Operação Periférica Simultânea 
On-line) e também era usada para saída. Com o spooling, os 1401 não eram mais necessários 
e acabava grande parte do trabalho de carga das fitas. 

Embora os sistemas operacionais de terceira geração fossem convenientes para cálculos 
científicos pesados e execuções de processamento de dados comerciais de grande volume, ba- 
sicamente eles ainda eram sistemas de lote. Muitos programadores sentiam falta dos tempos 
da primeira geração, quando eles tinham a máquina toda para si por algumas horas e, assim, 
podiam depurar seus programas rapidamente. Com os sistemas de terceira geração, o tempo 
entre submeter um job e receber a saída era freqiientemente de várias horas, de modo que uma 
vírgula colocada em lugar errado podia fazer uma compilação falhar e o programador perder 
metade do dia. 

Essa necessidade de um tempo de resposta curto abriu caminho para o compartilha- 
mento do tempo (time sharing), uma variante da multiprogramação na qual cada usuário 
tem um terminal on-line. Em um sistema de tempo compartilhado, se 20 usuários estivessem 
conectados e 17 deles estivessem pensando, conversando ou tomando café, a CPU podia ser 
alocada por turnos para os três jobs que quisessem o serviço. Como as pessoas que depuram 
programas normalmente utilizam comandos curtos (por exemplo, compilar uma procedure 
de cinco páginas) em vez de longos (por exemplo, ordenar um arquivo de um milhão de 
registros), o computador pode oferecer um serviço rápido e interativo para vários usuários e 
também trabalhar em segundo plano (background) com jobs grandes em lotes, quando a CPU 
estiver ociosa. O primeiro sistema sério de compartilhamento de tempo, o CTSS (Compatible 
Time Sharing System), foi desenvolvido no M.LT. em um 7094 especialmente modificado 
(Corbató et al., 1962). Entretanto, o compartilhamento de tempo não se tornou popular até 
que o hardware de proteção necessário se tornou difundido, durante a terceira geração. 

Após o sucesso do sistema CTSS, o MIT, o Bell Labs e a General Electric (na época, 
um importante fabricante de computadores) decidiram dedicar-se ao desenvolvimento de um 
“computer utility”*, uma máquina que suportaria centenas de usuários de tempo compartilha- 
do simultaneamente. Seu modelo era o sistema de distribuição de eletricidade — quando preci- 
sa de energia elétrica, você simplesmente insere um plugue na tomada da parede e, dentro do 
possível, toda a energia que precisar estará lá. Os projetistas desse sistema, conhecido como 
MULTICS (MULTiplexed Information and Computing Service — Serviço de Computação 
e Informação Multiplexado), imaginaram uma única máquina enorme fornecendo poder de 
computação para todos na região de Boston. A idéia de que máquinas muito mais poderosas 
do que seu computador de grande porte GE-645 seriam vendidas aos milhões por menos de 
mil dólares, apenas 30 anos depois, era pura ficção científica, como seria nos dias de hoje a 
idéia de trens supersônicos e transatlânticos submarinos. 


* Usaremos os termos procedure, procedimento, sub-rotina e função indistintamente neste livro. 


* N. de R. T.: Utility neste caso tem o sentido de um serviço público, indicando um recurso computacional amplamente dispo- 


nível. 
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O MULTICS foi um sucesso misto. Ele foi projetado para suportar centenas de usuários 
em uma máquina apenas ligeiramente mais poderosa do que um PC baseado no Intel 80386, 
embora tivesse muito mais capacidade de E/S. Isso não é tão louco quanto parece, pois na- 
quela época as pessoas sabiam escrever programas pequenos e eficientes, uma habilidade 
que subsequentemente foi perdida. Houve muitas razões para o MULTICS não tomar conta 
do mundo, não sendo a menor delas, o fato de ter sido escrito em PL/I e que o compilador 
de PL/I estava anos atrasado e mal funcionava quando finalmente chegou ao mercado. Além 
disso, o MULTICS era enormemente ambicioso para sua época, semelhantemente à máquina 
analítica de Charles Babbage no século XIX. 

O MULTICS introduziu muitas idéias embrionárias na literatura sobre computadores, 
mas transformá-lo em um produto sério e em um sucesso comercial foi muito mais difícil do 
que o esperado. O Bell Labs retirou-se do projeto e a General Electric desistiu completamen- 
te do negócio de computadores. Entretanto, o M.I.T. persistiu e finalmente fez o MULTICS 
funcionar. Por fim, ele foi vendido como um produto comercial pela empresa que adquiriu o 
ramo de computadores da GE (a Honeywell) e instalado por cerca de 80 empresas e univer- 
sidades importantes do mundo todo. Embora em número pequeno, os usuários do MULTICS 
eram extremamente leais. A General Motors, a Ford e a Agência de Segurança Nacional dos 
EUA, por exemplo, só desligaram seus sistemas MULTICS no final dos anos 90. O último 
MULTICS que estava em funcionamento, no Departamento de Defesa Nacional canadense, 
foi desligado em outubro de 2000. Apesar de sua falta de sucesso comercial, o MULTICS 
teve uma enorme influência sobre os sistemas operacionais subsegiientes. Existem muitas in- 
formações sobre ele (Corbató et al., 1972; Corbató e Vyssotsky, 1965; Daley e Dennis, 1968; 
Organick, 1972; e Saltzer, 1974). Ele também tem um site web ainda ativo, www. multicians. 
org, com muitas informações sobre o sistema, seus projetistas e seus usuários. 

Não se ouve falar mais da expressão computer utility, mas a idéia ganhou vida nova 
recentemente. Em sua forma mais simples, os PCs ou estações de trabalho (PCs de topo de 
linha) em uma empresa, ou em uma sala de aula, podem estar conectados, por meio de uma 
rede local (LAN), a um servidor de arquivos no qual todos os programas e dados estão ar- 
mazenados. Então, um administrador precisa instalar e proteger apenas um conjunto de pro- 
gramas e dados, e pode reinstalar facilmente software local em um PC ou estação de trabalho 
que não esteja funcionando bem, sem se preocupar com a recuperação ou com a preservação 
de dados locais. Em ambientes mais heterogêneos, foi desenvolvida uma classe de software 
chamada middleware para fazer a ligação entre usuários locais e arquivos e entre programas e 
bancos de dados armazenados em servidores remotos. O middleware faz os computadores in- 
terligados em rede parecerem locais para os PCs ou para as estações de trabalho dos usuários 
individuais e apresenta uma interface uniforme com o usuário, mesmo que haja uma ampla 
variedade de servidores, PCs e estações de trabalho diferentes em uso. A World Wide Web é 
um exemplo. Um navegador web apresenta documentos para um usuário de maneira unifor- 
me e um documento visualizado no navegador de um usuário pode ser composto por texto 
de um servidor e elementos gráficos de um outro, apresentados em um formato determinado 
por uma folha de estilos (style sheets) de um terceiro servidor. Normalmente, as empresas e 
universidades utilizam uma interface web para acessar bancos de dados e executar programas 
em um computador em outro prédio ou mesmo em outra cidade. O middleware parece ser 
o sistema operacional de um sistema distribuído, mas na realidade não é um sistema ope- 
racional e esse assunto está fora dos objetivos deste livro. Para ver mais informações sobre 
sistemas distribuídos, consulte Tanenbaum e Van Steen (2002). 

Outro desenvolvimento importante durante a terceira geração foi o fenomenal cresci- 
mento dos minicomputadores, começando com o PDP-1 da DEC (Digital Equipment Com- 
pany), em 1961. O PDP-1 tinha apenas 4K de palavras de 18 bits, mas a US$120.000 por 


32 SISTEMAS OPERACIONAIS 


1.2.4 


máquina (menos de 5% do preço de um 7094), foi um grande sucesso de vendas. Para certos 
tipos de trabalho não numéricos, ele era quase tão rápido quanto o 7094 e deu origem a toda 
uma nova indústria. Rapidamente, foi seguido por uma série de outros PDPs (ao contrário da 
família da IBM, todos incompatíveis), culminando no PDP-11. 

Um dos cientistas da computação do Bell Labs, que tinha trabalhado no projeto do 
MULTICS, Ken Thompson, encontrou um pequeno minicomputador PDP-7 que ninguém 
usava e começou a escrever uma versão monousuário simplificada do MULTICS. Posterior- 
mente, esse trabalho transformou-se no sistema operacional UNIX, que se tornou popular no 
mundo acadêmico, entre órgãos do governo e em muitas empresas. 

A história do UNIX foi contada em outros textos (por exemplo, Salus, 1994). Como o 
código-fonte estava amplamente disponível, várias organizações desenvolveram suas próprias 
versões (incompatíveis), que levaram ao caos. Duas versões importantes foram desenvolvi- 
das, o System V, da AT&T, e a BSD (Berkeley Software Distribution), da Universidade da 
Califórnia, em Berkeley. Elas também tiveram pequenas variantes, agora incluindo FreeBSD, 
OpenBSD e NetBSD. Para tornar possível escrever programas que pudessem ser executados 
em qualquer sistema UNIX, o IEEE desenvolveu um padrão para o UNIX, chamado POSIX, 
que a maioria das versões de UNIX agora o suportam. O padrão POSIX define uma interfa- 
ce mínima de chamadas de sistema que os sistemas UNIX compatíveis devem suportar. Na 
verdade, agora, outros sistemas operacionais também oferecem suporte a interface POSIX. 
As informações necessárias para se escrever software compatível com o padrão POSIX estão 
disponíveis em livros (IEEE, 1990; Lewine, 1991) e on-line, como a “Single UNIX Specifica- 
tion” do Open Group, que se encontra no endereço www.unix.org. Posteriormente, neste capí- 
tulo, quando nos referirmos ao UNIX, incluímos também todos esses sistemas, a não ser que 
mencionemos de outra forma. Embora sejam diferentes internamente, todos eles suportam o 
padrão POSIX; portanto, para o programador, eles são bastante semelhantes. 


A quarta geração (1980-hoje): computadores pessoais 

Com o desenvolvimento dos circuitos LSI (Large Scale Integration — integração em larga 
escala), chips contendo milhares de transistores em um centímetro quadrado de silício, surgiu 
a era do computador pessoal baseado em microprocessador. Em termos de arquitetura, os 
computadores pessoais (inicialmente chamados de microcomputadores) não eram muito 
diferentes dos minicomputadores da classe PDP-11, mas em termos de preço, eles certamente 
eram diferentes. O minicomputador também tornou possível que um departamento de uma 
empresa ou universidade tivesse seu próprio computador. O microcomputador tornou possí- 
vel que uma pessoa tivesse seu próprio computador. 

Havia várias famílias de microcomputadores. Em 1974, a Intel apareceu com o 8080, 
o primeiro microprocessador de 8 bits de propósito geral. Diversas empresas produziram 
sistemas completos usando o 8080 (ou o microprocessador compatível da Zilog, o Z80) e o 
sistema operacional CP/M (Control Program for Microcomputers), de uma empresa cha- 
mada Digital Research, foi amplamente usado neles. Muitos programas aplicativos foram 
escritos para executar no CP/M e ele dominou o mundo da computação pessoal por cerca 
de 5 anos. 

A Motorola também produziu um microprocessador de 8 bits, o 6800. Um grupo de 
engenheiros deixou a Motorola para formar a MOS Technology e fabricar a CPU 6502, após 
a Motorola ter rejeitado as melhorias sugeridas por eles para o 6800. O 6502 foi a CPU de 
vários sistemas antigos. Um deles, o Apple II, se tornou um importante concorrente dos sis- 
temas CP/M nos mercados doméstico e educacional. Mas o CP/M era tão popular que muitos 
proprietários de computadores Apple II adquiriram placas com o coprocessador Z-80 para 
executar CP/M, pois a CPU 6502 não era compatível com este sistema operacional. As pla- 
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cas CP/M eram comercializadas por uma pequena empresa chamada Microsoft, que também 
tinha um nicho de mercado, fornecendo interpretadores BASIC, usado por vários microcom- 
putadores que executavam o CP/M. 

A geração seguinte de microprocessadores foram os sistemas de 16 bits. A Intel apare- 
ceu com o 8086 e, no início dos anos 80, a IBM projetou o IBM PC utilizando o 8088 da Intel 
(internamente, um 8086, com um caminho de dados externo de 8 bits). A Microsoft ofereceu 
à IBM um pacote que incluía o BASIC e um sistema operacional, o DOS (Disk Operating 
System), originalmente desenvolvido por outra empresa — a Microsoft comprou o produto e 
contratou o autor original para aprimorá-lo. O sistema revisado foi chamado de MS-DOS 
(MicroSoft Disk Operating System) e rapidamente dominou o mercado do IBM PC. 

O CP/M, o MS-DOS e o Apple DOS eram todos sistemas de linha de comando: os 
usuários digitavam comandos no teclado. Anos antes, Doug Engelbart, do Stanford Research 
Institute, tinha inventado a GUI (Graphical User Interface — interface gráfica com o usuá- 
rio), contendo janelas, ícones, menus e mouse. Steve Jobs, da Apple, viu a possibilidade de 
um computador pessoal realmente amigável (para usuários que não sabiam nada sobre com- 
putadores e não queriam aprender) e o Macintosh da Apple foi anunciado no início de 1984. 
Ele usava a CPU 68000 de 16 bits da Motorola e tinha 64 KB de memória ROM (Read Only 
Memory — memória somente de leitura), para suportar a GUI. Com o passar dos anos, o Ma- 
cintosh evoluiu. As CPUs subseqiientes da Motorola eram verdadeiros sistemas de 32 bits e 
posteriormente a Apple mudou para as CPUs PowerPC da IBM, com arquitetura RISC de 32 
bits (e, posteriormente, 64 bits). Em 2001, a Apple fez uma mudança importante no sistema 
operacional, lançando o Mac OS X, com uma nova versão da GUI Macintosh sobre o UNIX 
de Berkeley. E, em 2005, a Apple anunciou que estaria mudando para processadores Intel. 

Para concorrer com o Macintosh, a Microsoft inventou o Windows. Originalmente, o 
Windows era apenas um ambiente gráfico sobre o MS-DOS de 16 bits (isto é, era mais um 
shell do que um verdadeiro sistema operacional). Entretanto, as versões atuais do Windows 
são descendentes do Windows NT, um sistema de 32 bits completo, reescrito desde o início. 

O outro concorrente importante no mundo dos computadores pessoais é o UNIX (e 
seus vários derivados). O UNIX é mais poderoso em estações de trabalho e em outros 
computadores topo de linha, como os servidores de rede. Ele é especialmente difundido 
em máquinas equipadas com chips RISC de alto desempenho. Em computadores baseados 
em Pentium, o Linux está se tornando uma alternativa popular ao Windows para os estu- 
dantes e, cada vez mais, para muitos usuários corporativos. (Neste livro, usaremos o termo 
“Pentium” para nos referirmos à família Pentium inteira, incluindo os microprocessadores 
Celeron, de baixo poder computacional e os Xeon, de mais alto poder computacional e seus 
compatíveis AMD). 

Embora muitos usuários de UNIX, especialmente programadores experientes, prefi- 
ram uma interface baseada em comandos a uma GUI, praticamente todos os sistemas UNIX 
suportam um sistema de janelas chamado X Window, desenvolvido no M.I.T. Esse sistema 
trata do gerenciamento básico de janelas, permitindo aos usuários criar, excluir, mover e re- 
dimensionar janelas usando um mouse. Fregiientemente, uma GUI completa, como a Motif, 
é disponibilizada para funcionar sobre o sistema X Window, proporcionando ao UNIX a apa- 
rência e o comportamento do Macintosh ou do Microsoft Windows para os usuários UNIX 
que assim o desejarem. 

Um desenvolvimento interessante, que começou durante meados dos anos 80, é o cres- 
cimento das redes de computadores pessoais executando sistemas operacionais de rede e 
sistemas operacionais distribuídos (Tanenbaum e Van Steen, 2002). Em um sistema opera- 
cional de rede, os usuários sabem da existência de vários computadores e podem se conectar 
a máquinas remotas e copiar arquivos de uma para outra. Cada máquina executa seu próprio 
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sistema operacional local e tem seu próprio usuário (ou usuários) local. Basicamente, as má- 
quinas são independentes entre si. 

Os sistemas operacionais de rede não são fundamentalmente diferentes dos sistemas 
operacionais locais a uma máquina. Obviamente, eles precisam de uma controladora de inter- 
face de rede e de algum software de baixo nível para fazê-los funcionar, assim como de pro- 
gramas para obter login remoto e acesso remoto aos arquivos, mas essas adições não mudam 
a estrutura básica do sistema operacional. 

Em contraste, um sistema operacional distribuído é aquele que aparece para seus usuá- 
rios como um sistema de um processador tradicional, mesmo sendo composto, na verdade, 
por vários processadores. Os usuários não devem saber onde seus programas estão sendo exe- 
cutados nem onde seus arquivos estão localizados; tudo isso deve ser manipulado automática 
e eficientemente pelo sistema operacional. 

Os verdadeiros sistemas operacionais distribuídos exigem mais do que apenas adicionar 
um código em um sistema operacional centralizados, pois os sistemas distribuídos e os cen- 
tralizados diferem de maneiras importantes. Os sistemas distribuídos, por exemplo, freqüen- 
temente permitem que os aplicativos sejam executados em vários processadores ao mesmo 
tempo, exigindo assim algoritmos de escalonamento mais complexos para otimizar o volume 
de paralelismo. 

Muitas vezes, os atrasos de comunicação em rede significam que esses algoritmos (e 
outros) devam ser executados com informações incompletas, desatualizadas ou mesmo incor- 
retas. Essa situação é radicalmente diferente de um sistema operacional centralizado, no qual 
se tem informações completas sobre o estado do sistema. 


A história do MINIX 3 


No início, o código-fonte do UNIX (versão 6) estava amplamente disponível, sob licença da 
AT&T, e era muito estudado. John Lions, da Universidade de New South Wales, na Austrália, 
escreveu um livro descrevendo seu funcionamento, linha por linha (Lions, 1996), e ele foi 
usado (com permissão da AT&T) como livro texto em muitos cursos universitários sobre 
sistemas operacionais. 

Quando a AT&T lançou a versão 7, começou a perceber que o UNIX era um produto 
comercial valioso e, assim, distribuiu essa versão com uma licença proibindo o estudo do 
código-fonte em cursos para evitar o risco de expor seu status de segredo comercial. Muitas 
universidades obedeceram simplesmente eliminando o estudo do UNIX e ensinando apenas 
a teoria. 

Infelizmente, ensinar apenas a teoria deixa o aluno com uma visão prejudicada do que 
um sistema operacional realmente é. Os assuntos teóricos normalmente abordados em deta- 
lhes em cursos e livros sobre sistemas operacionais, como os algoritmos de escalonamento, 
não têm tanta importância na prática. Os assuntos realmente importantes, como F/S e siste- 
mas de arquivos, geralmente são abandonados, pois há pouca teoria a respeito. 

Para corrigir essa situação, um dos autores deste livro (Tanenbaum) decidiu escrever 
um novo sistema operacional a partir de zero, que seria compatível com o UNIX do ponto 
de vista do usuário, mas completamente diferente por dentro. Por não usar sequer uma 
linha do código da AT&T, esse sistema evita as restrições de licenciamento; assim, ele 
pode ser usado para estudo individual ou em classe. Desse modo, os leitores podem disse- 
car um sistema operacional real para ver o que há por dentro, exatamente como os alunos 
de biologia dissecam rãs. Ele foi chamado de MINIX e foi lançado em 1987, com seu 
código-fonte completo para qualquer um estudar ou modificar. O nome MINIX significa 
mini-UNIX, pois ele é pequeno o bastante até para quem não é especialista poder entender 
seu funcionamento. 
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Além da vantagem de eliminar os problemas jurídicos, o MINIX tem outra vantagem 
em relação ao UNIX. Ele foi escrito uma década depois deste e foi estruturado de maneira 
mais modular. Por exemplo, desde a primeira versão do MINIX, o sistema de arquivos e o 
gerenciador de memória não fazem parte do sistema operacional, mas são executados como 
programas de usuário. Na versão atual (MINIX 3) essa modularização foi ampliada para os 
drivers de dispositivos de E/S, todos os quais (com exceção do driver de relógio) são exe- 
cutados como programas de usuário. Outra diferença é que o UNIX foi projetado para ser 
eficiente; o MINIX foi projetado para ser legível (se é que alguém pode falar de qualquer 
programa com centenas de páginas como sendo legível). O código do MINIX, por exemplo, 
contém milhares de comentários. 

O MINIX foi originalmente projetado para ser compatível com o UNIX versão 7 (V7). 
A versão 7 foi usada como modelo devido a sua simplicidade e elegância. Às vezes, diz-se 
que a versão 7 foi um aprimoramento não apenas em relação a todas as versões antecedentes, 
mas também em relação a todas as suas sucessoras. Com o advento do POSIX, o MINIX 
começou a evoluir para o novo padrão, embora mantendo a compatibilidade com as versões 
anteriores dos programas existentes. Esse tipo de evolução é comum na indústria dos compu- 
tadores, pois qualquer fornecedor deseja introduzir um novo sistema sem provocar grandes 
transformações ou transtornos aos seus clientes atuais. A versão do MINIX descrita neste 
livro, MINIX 3, é baseada no padrão POSIX. 

Assim como o UNIX, o MINIX foi escrito na linguagem de programação C e destinado 
a ser facilmente portado para vários computadores. A implementação inicial foi para o IBM 
PC. Subsegientemente, o MINIX foi portado para várias outras plataformas. Para manter a 
filosofia do “quanto menor, melhor”, originalmente, o MINIX nem mesmo exigia um disco 
rígido para funcionar (em meados dos anos 80, os discos rígidos ainda eram uma novidade 
cara). À medida que o MINIX foi crescendo em funcionalidade e tamanho, chegou um ponto 
em que foi necessário ter-se disco rígido, mas mantendo a filosofia “quanto menor, melhor”, 
uma partição de 200 MB é suficiente (contudo, para sistemas embarcados nenhum disco 
rígido é necessário). Em contraste, mesmo os sistemas Linux “enxutos” exigem 500 MB de 
espaço em disco e vários GB são necessários para instalar aplicativos comuns. 

Para o usuário médio sentado diante de um IBM PC, executar o MINIX é semelhante 
a executar o UNIX. Todos os programas básicos estão presentes, como cat, grep, ls, make e 
o shell, e executam as mesmas funções de seus equivalentes UNIX. Assim como o sistema 
operacional em si, todos esses programas utilitários foram completamente reescritos a partir 
de zero pelo autor, seus alunos e algumas outras pessoas dedicadas, sem nenhum código pa- 
tenteado da AT&T ou de outros. Agora existem muitos outros programas distribuídos gratui- 
tamente e, em muitos casos, têm sido portados (recompilados) com sucesso no MINIX. 

O MINIX continuou a ser desenvolvido por uma década e o MINIX 2 foi lançado em 
1997, junto com a segunda edição deste livro, que descrevia a nova versão. As alterações 
feitas entre as versões 1 e 2 foram significativas (por exemplo, do modo real de 16 bits em 
um 8088 usando disquetes, para o modo protegido de 32 bits em um 386 usando um disco 
rígido), mas evolutivas. 

O desenvolvimento continuou lento, mas sistematicamente, até 2004, quando Tanen- 
baum se convenceu de que o software estava ficando grande demais e não confiável, ten- 
do decidido melhorar novamente o segmento MINIX ligeiramente adormecido. Junto com 
seus alunos e programadores da Vrije Universiteit, em Amsterdã, ele produziu o MINIX 3, 
um reprojeto significativo do sistema, reestruturando bastante o núcleo, reduzindo seu ta- 
manho e dando ênfase à modularidade e à confiabilidade. A nova versão se destinava tanto a 
PCs quanto a sistemas embarcados, onde a compacidade, modularidade e confiabilidade são 
fundamentais. Embora algumas pessoas do grupo pedissem um nome completamente novo, 


36 


SISTEMAS OPERACIONAIS 


finalmente ficou decidido que ele se chamaria MINIX 3, pois o nome MINIX já era bem co- 
nhecido. Como uma analogia, quando a Apple abandonou seu próprio sistema operacional, o 
Mac OS 9, e o lançou como uma variante do UNIX da Berkeley, o nome escolhido foi Mac 
OS X, em vez de APPLIX ou algo assim. Mudanças fundamentais semelhantes ocorreram na 
família Windows e seu nome foi mantido. 

O núcleo do MINIX 3 tem bem menos de 4000 linhas de código executável, com- 
paradas às milhões de linhas de código executável do Windows, do Linux, do FreeBSD e 
de outros sistemas operacionais. Um núcleo pequeno é importante, pois erros de núcleo 
são bem mais devastadores do que erros em programas de modo usuário, e mais código 
significa mais erros. Um estudo cuidadoso mostrou que o número de erros detectados por 
1000 linhas de código executável varia de 6 a 16 (Basili e Perricone, 1984). O número real 
de erros provavelmente é muito mais alto, pois os pesquisadores só puderam contar erros 
relatados. Um outro estudo (Ostrand et al., 2004) mostrou que, mesmo depois de mais de 
uma dezena de lançamentos, em média 6% de todos os arquivos continha erros que foram 
relatados posteriormente e, após certo ponto, o nível de erros tende a estabilizar, em vez de 
tender assintoticamente a zero. Esse resultado é corroborado pelo fato de que, quando um 
verificador de modelo muito simples e automatizado foi posto em versões estáveis do Linux 
e do OpenBSD, ele descobriu centenas de erros de núcleo, esmagadoramente presentes em 
drivers de dispositivos (Chou et al., 2001; e Engler et al., 2001). Esse é o motivo pelo qual 
os drivers de dispositivos foram retirados do núcleo no MINIX 3; eles podem causar menos 
danos no modo usuário. 

Neste livro, o MINIX 3 será usado como exemplo. Entretanto, a maioria dos comentá- 
rios sobre as chamadas de sistema do MINIX 3 (em oposição aos comentários sobre o código 
em si), também se aplica aos outros sistemas UNIX. Esta observação deve ser lembrada ao 
se ler o texto. 

Algumas palavras sobre o Linux e seu relacionamento com o MINIX podem ser de 
interesse para alguns leitores. Logo depois que o MINIX foi lançado, foi formado um grupo 
de discussão na USENET, comp.os.minix, para discuti-lo. Dentro de poucas semanas o gru- 
po tinha 40.000 assinantes, a maioria dos quais querendo acrescentar um grande número de 
recursos novos no MINIX para torná-lo maior e melhor (bem, pelo menos maior). Todos os 
dias, centenas deles davam sugestões, idéias e, frequentemente, forneciam trechos de código- 
fonte. O autor do MINIX conseguiu resistir a essa investida por vários anos, para manter o 
MINIX limpo o suficiente para os alunos o entenderem, e pequeno o bastante para que pudes- 
se ser executado nos computadores que eles podiam comprar. Para as pessoas que não tinham 
muita consideração com o MS-DOS, a existência do MINIX (com o código-fonte) como uma 
alternativa era mesmo um motivo para finalmente sair e comprar um PC. 

Uma dessas pessoas foi um estudante finlandês chamado Linus Torvalds. Torvalds ins- 
talou o MINIX em seu novo PC e estudou cuidadosamente o código-fonte. Ele queria ler os 
grupos de discussão da USENET (como o comp.os.minix) em seu próprio PC, em vez de 
usar o da universidade, mas faltavam no MINIX alguns recursos de que precisava; assim, 
ele escreveu um programa para fazer isso, mas logo descobriu que precisava de um driver de 
terminal diferente, de modo que também o escreveu. Em seguida, ele queria fazer download 
e salvar mensagens postadas; portanto, escreveu um driver de disco e depois um sistema de 
arquivos. Em agosto de 1991, ele tinha produzido um núcleo primitivo. Em 25 de agosto de 
1991, ele o anunciou no comp.os.minix. Esse anúncio atraiu outras pessoas para ajudá-lo e, 
em 13 de março de 1994, foi lançado o Linux 1.0. Assim nasceu o Linux. 

O Linux se tornou um dos sucessos notáveis do movimento do código-fonte aberto 
(que o MINIX ajudou a iniciar). O Linux está superando o UNIX (e o Windows) em mui- 
tos ambientes, parcialmente porque agora se encontram disponíveis PCs comerciais que 
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suportam o Linux com desempenho equiparável a algumas implementações proprietárias 
de UNIX para sistemas RISC. Outros programas de software de código-fonte aberto, nota- 
damente o servidor web Apache e o banco de dados MySQL, funcionam bem com o Linux 
no mundo comercial. O Linux, o Apache, o MySQL e as linguagens de programação de 
código-fonte aberto Perl e PHP são fregqiientemente usados em conjunto nos servidores web 
e às vezes são referidos pelo acrônimo LAMP. Para obter mais informações sobre a história 
do Linux e sobre software de código-fonte aberto, consulte DiBona et al. (1999), Moody 
(2001) e Naughton (2000). 


CONCEITOS DE SISTEMA OPERACIONAL 


A interface entre o sistema operacional e os programas de usuário é definida pelo conjunto de 
“instruções estendidas” fornecidas pelo sistema operacional. Essas instruções estendidas são 
tradicionalmente conhecidas como chamadas de sistema. Para entendermos realmente o que 
os sistemas operacionais fazem, devemos examinar essa interface detidamente. As chamadas 
disponíveis na interface variam de um sistema operacional para outro (embora os conceitos 
subjacentes tendem a ser semelhantes). 

Assim, somos obrigados a fazer uma escolha entre (1) generalidades vagas (os “sistemas 
operacionais têm chamadas de sistema para ler arquivos”) e (2) algum sistema específico (“o 
MINIX 3 tem uma chamada de sistema read com três parâmetros: um para especificar o arqui- 
vo, um para dizer onde os dados devem ser transferidos e um para informar quantos bytes de- 
vem ser lidos”). Escolhemos a última abordagem. Ela é mais trabalhosa, mas oferece uma visão 
melhor do que os sistemas operacionais realmente fazem. Na Seção 1.4, veremos com detalhes 
as chamadas de sistema básicas presentes no UNIX (incluindo as diversas versões de BSD), no 
Linux e no MINIX 3. Para simplificar, vamos nos referir apenas ao MINIX 3, mas as chamadas 
de sistema correspondentes do UNIX e do Linux são baseadas no POSIX, na maioria dos casos. 
Entretanto, antes de vermos as chamadas de sistema reais, é interessante ver um panorama do 
MINIX 3 para ter uma visão geral do que é um sistema operacional como um todo. Essa visão 
geral se aplica igualmente bem ao UNIX e ao Linux, conforme mencionado anteriormente. 

As chamadas de sistema do MINIX 3 dividem-se, grosso modo, em duas categorias 
amplas: aquelas que tratam com processos e aquelas que tratam com o sistema de arquivos. 
Examinaremos agora cada uma delas separadamente. 


Processos 


Um conceito importante no MINIX 3, e em todos os sistemas operacionais, é o processo. Um 
processo é basicamente um programa em execução. Associado a cada processo está o espaço de 
endereçamento, uma lista de posições de memória a partir de um mínimo (normalmente, 0) até 
um máximo que o processo pode ler e escrever. O espaço de endereçamento contém o programa 
executável, os dados do programa e sua pilha. Também associado a cada processo está um con- 
junto de registradores, incluindo o contador de programa, o ponteiro da pilha e outros registrado- 
res de hardware e todas as outras informações necessárias para a execução do programa. 

Voltaremos ao conceito de processo com muito mais detalhes no Capítulo 2, mas, por 
enquanto, a maneira mais fácil de entender um processo intuitivamente é pensar nos sistemas 
de multiprogramação. Periodicamente, o sistema operacional decide interromper a execução 
de um processo e iniciar a execução de outro, por exemplo, porque o primeiro ultrapassou sua 
parcela de tempo da CPU no último segundo. 

Quando um processo é temporariamente suspenso, como esse, posteriormente ele deve 
ser reiniciado exatamente no mesmo estado em que estava quando foi interrompido. Isso 
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significa que durante a suspensão todas as informações sobre o processo devem ser explicita- 
mente salvas em algum lugar. Por exemplo, o processo pode ter vários arquivos simultanea- 
mente abertos para leitura. Associado a cada um desses arquivos existe um ponteiro forne- 
cendo a posição corrente (isto é, o número do byte ou registro a ser lido em seguida). Quando 
um processo é temporariamente suspenso, todos esses ponteiros devem ser salvos para que 
a chamada read executada depois que o processo for reiniciado leia os dados corretos. Em 
muitos sistemas operacionais, todas as informações sobre cada processo, que não o conteúdo 
de seu próprio espaço de endereçamento, são armazenadas em uma tabela do sistema opera- 
cional chamada de tabela de processos, que é um array (ou lista encadeada) de estruturas, 
uma para cada processo correntemente existente. 

Assim, um processo (suspenso) consiste em seu espaço de endereçamento, normal- 
mente chamado de imagem do núcleo (em homenagem às memórias de núcleo magnético 
usadas antigamente), e sua entrada na tabela de processos, que contém seus registradores, 
entre outras coisas. 

As principais chamadas de sistema de gerenciamento de processos são aquelas que 
tratam da criação e do término de processos. Considere um exemplo típico. Um processo cha- 
mado interpretador de comandos, ou shell, lê comandos de um terminal. O usuário acabou 
de digitar um comando solicitando a compilação de um programa. Agora o shell deve criar 
um novo processo que executará o compilador. Quando esse processo termina a compilação, 
executa uma chamada de sistema para ele próprio terminar. 

No Windows, e em outros sistemas operacionais que possuem uma GUI, dar um clique 
(ou um clique duplo) em um ícone na área de trabalho ativa um programa, exatamente como 
aconteceria se seu nome fosse digitado no prompt de comandos. Embora não discutamos 
muito as GUIs aqui, na realidade elas são simples interpretadores de comandos. 

Se um processo pode criar um ou mais processos (normalmente denominados como 
processos filhos) e esses processos por sua vez podem criar novos processos filhos, rapida- 
mente chegamos à estrutura em árvore da Figura 1-5. Os processos relacionados que estão 
cooperando para fazer algum trabalho frequentemente precisam se comunicar uns com os ou- 
tros e sincronizar suas atividades. Nos referimos a isso como comunicação entre processos 
(Inter Process Communication — IPC) e será tratada em detalhes no Capítulo 2. 


Figura 1-5 Uma árvore de processos. O processo A criou dois processos filhos, Be C. O 
processo B criou três processos filhos, D, E e E. 


São disponíveis outras chamadas de sistema para os processos solicitarem mais memó- 
ria (ou liberar memória não utilizada), esperarem que um processo filho termine e substituí- 
rem seu próprio código por outro diferente. 

Ocasionalmente, há necessidade de transmitir informações para um processo em exe- 
cução que não está parado esperando por elas. Por exemplo, um processo que esteja se co- 
municando com outro processo em um computador diferente faz isso enviando mensagens 
através da rede. Para evitar a possibilidade de perda de uma mensagem, ou de sua resposta, o 
remetente pode solicitar que seu próprio sistema operacional o notifique, após alguns segun- 
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dos especificados, para que ele retransmita a mensagem caso nenhum sinal de confirmação 
tenha sido recebido. Após configurar esse tempo limite (timeout), o programa pode continuar 
a fazer outro trabalho. 

Quando tiver decorrido o tempo em segundos especificado, o sistema operacional envia 
um sinal de alarme para o processo. O sinal faz com que o processo suspenda temporaria- 
mente o que está fazendo, salve seus registradores na pilha e comece a executar um pro- 
cedimento especial de tratamento de sinal, por exemplo, para retransmitir uma mensagem 
presumivelmente perdida. Quando a rotina de tratamento de sinal tiver terminado, o processo 
em execução será reiniciado no estado em que estava imediatamente antes do recebimento do 
sinal. Os sinais são equivalentes às interrupções de hardware, só que em software. Eles são 
gerados por diversas causas, além da expiração de tempos limites. Muitas interrupções detec- 
tadas pelo hardware, como a execução de uma instrução inválida, ou o uso de um endereço 
inválido, também são convertidas em sinais para o processo causador. 

Cada pessoa autorizada a usar um sistema MINIX 3 recebe uma UID (User IDentifi- 
cation — identificação de usuário) do administrador do sistema. Todo processo tem a UID da 
pessoa que o criou. Um processo filho tem a mesma UID de seu pai. Os usuários podem ser 
membros de grupos, cada um dos quais com uma GID (Group IDentification — identificação 
de grupo). 

Uma UID, denominada superusuário (no UNIX), tem poder especial e pode violar 
muitas das regras de proteção. Nas grandes instalações, apenas o administrador do sistema 
conhece a senha necessária para se tornar superusuário, mas muitos usuários normais (espe- 
cialmente estudantes) dedicam um esforço considerável tentando encontrar falhas no sistema 
que permitam a eles se tornarem superusuários sem a necessidade de senha. O superusuário 
também é denominado de root do sistema. 

Estudaremos os processos, a comunicação entre processos e os problemas relacionados, 
no Capítulo 2. 


Arquivos 


A outra categoria ampla de chamadas de sistema se relaciona ao sistema de arquivos. Con- 
forme mencionado anteriormente, uma função importante do sistema operacional é ocultar 
as peculiaridades dos discos e de outros dispositivos de E/S, e apresentar ao programador um 
modelo abstrato, agradável e claro, dos arquivos independentes dos dispositivos que os arma- 
zenam. Obviamente, são necessárias chamadas de sistema para criar, remover, ler e escrever 
arquivos. Antes que um arquivo possa ser lido, ele deve ser aberto; depois de lido, ele deve ser 
fechado; portanto, são fornecidas chamadas para fazer essas coisas. 

Para fornecer um lugar para manter os arquivos, o MINIX 3 tem o conceito de diretório 
como uma maneira de agrupar os arquivos. Um aluno, por exemplo, poderia ter um diretório 
para cada curso que estivesse fazendo (para os programas necessários para esse curso), outro 
para seu correio eletrônico e outro ainda para sua página web pessoal. Então, são necessárias 
chamadas de sistema para criar e remover diretórios. Também são fornecidas chamadas para 
colocar um arquivo existente em um diretório e para remover um arquivo de um diretório. As 
entradas do diretório podem ser arquivos ou outros diretórios. Esse modelo também origina 
uma hierarquia — o sistema de arquivos —, como se vê na Figura 1-6. 

Tanto o processo quanto as hierarquias de arquivos são organizadas como árvores, mas 
a semelhança pára aí. As hierarquias de processos normalmente não são muito profundas 
(mais de três níveis é incomum), enquanto as hierarquias de arquivos normalmente têm qua- 
tro, cinco ou até mais níveis de profundidade. As hierarquias de processos normalmente têm 
vida curta, em geral, alguns minutos no máximo, enquanto a hierarquia de diretórios pode 
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Figura 1-6 Um sistema de arquivos para um departamento de uma universidade. 


existir por vários anos. A posse e a proteção também diferem para processos e arquivos. Nor- 
malmente, apenas um processo pai pode controlar ou mesmo acessar um processo filho, mas 
quase sempre existem mecanismos para permitir que arquivos e diretórios sejam lidos por um 
grupo maior do que apenas o proprietário. 

Todo arquivo dentro da hierarquia de diretórios pode ser especificado por meio de seu 
nome de caminho a partir do topo da hierarquia, o diretório-raiz. Os nomes de caminho 
absoluto consistem na lista dos diretórios que devem ser percorridos a partir do diretório-raiz 
para se chegar ao arquivo, com barras separando os componentes. Na Figura 1-6, o caminho 
para o arquivo CS101 é /Faculdade/Prof.Brown/Cursos/CS101. A primeira barra indica que 
o caminho é absoluto; isto é, começa no diretório-raiz. No Windows, o caractere de barra 
invertida (\) é usado como separador, em vez do caractere de barra normal (/), de modo que o 
caminho do arquivo dado anteriormente seria escrito como NaculdadaProf.BrownACursosN 
CS101. Neste livro, usaremos a convenção do UNIX para caminhos. 

A todo instante, cada processo tem um diretório de trabalho corrente, no qual os no- 
mes de caminho que não começam com uma barra são procurados. Esses caminhos são de- 
nominados de caminhos relativos. Como exemplo, na Figura 1-6, se /Faculdade/Prof.Brown 
fosse o diretório de trabalho, então empregar o nome de caminho Cursos/CS101 resultaria no 
mesmo arquivo que o nome de caminho absoluto dado anteriormente. Os processos podem 
mudar seu diretório de trabalho executando uma chamada de sistema especificando o novo 
diretório de trabalho. 

No MINIX 3, os arquivos e diretórios são protegidos designando-se a cada um deles um 
código de proteção de onze bits. O código de proteção consiste em três campos de três bits: 
um para o proprietário, um para os outros membros do grupo do proprietário (os usuários são 
divididos em grupos pelo administrador do sistema) e um para as demais pessoas. Os dois 
bits restantes serão discutidos posteriormente. Cada campo tem um bit para acesso de leitura, 


CAPÍTULO 1 e INTRODUÇÃO 41 


um bit para acesso de escrita e um bit para acesso de execução. Esses três bits são conhecidos 
como bits rwx. Por exemplo, o código de proteção rwxr-x--x significa que o proprietário 
pode ler, escrever ou executar o arquivo, que os outros membros do grupo podem ler ou exe- 
cutar (mas não escrever) o arquivo e que as demais pessoas podem executar (mas não ler nem 
escrever) o arquivo. Para um diretório (em oposição a um arquivo), x indica permissão de 
busca. Um traço significa que a permissão correspondente está ausente (o bit é zero). 

Antes que um arquivo possa ser lido ou escrito, ele deve ser aberto, momento este em 
que as permissões são verificadas. Se o acesso for permitido, o sistema retornará um valor in- 
teiro chamado descritor de arquivo para ser usado nas operações subsegiientes. Se o acesso 
for proibido, será retornado um código de erro (-1). 

Outro conceito importante no MINIX 3 é a montagem (mounting) de um sistema de 
arquivos. Quase todos os computadores pessoais têm uma ou mais unidades de CD-ROM nas 
quais CD-ROMs podem ser inseridos e removidos. Para fornecer uma maneira simples de 
tratar com mídia removível (CD-ROMs, DVDs, disquetes, Zip drives etc.), o MINIX 3 per- 
mite que o sistema de arquivos em um CD-ROM seja anexado à árvore principal. Considere 
a situação da Figura 1-7(a). Antes da chamada de sistema mount, o sistema de arquivos-raiz 
no disco rígido e um segundo sistema de arquivos em um CD-ROM estão separados e não 
relacionados. 


Raiz CD-ROM Raiz 


(a) 


Figura 1-7 (a) Antes da montagem, os arquivos na unidade de disco O não são acessíveis. 
(b) Após a montagem, eles fazem parte da hierarquia de arquivos. 


Isoladamente, o sistema de arquivos no CD-ROM não pode ser usado, pois não há como 
especificar nomes de caminho nele. O MINIX 3 não permite que os nomes de caminho te- 
nham como prefixo um nome ou um número de unidade de disco; é precisamente esse o tipo 
de dependência de dispositivo que os sistemas operacionais devem eliminar. Em vez disso, a 
chamada de sistema mount permite que o sistema de arquivos no CD-ROM seja anexado ao 
sistema de arquivos raiz onde o programa quiser que ele esteja. Na Figura 1-7(b), o sistema 
de arquivos na unidade de CD-ROM foi montado no diretório b, permitindo assim acesso aos 
arquivos /b/x e /b/. Se o diretório b contivesse originalmente quaisquer arquivos, eles não 
seriam acessíveis enquanto o CD-ROM estivesse montado, pois /b iria se referir ao diretório- 
raiz da unidade de CD-ROM. (Não ser capaz de acessar esses arquivos não é tão sério quando 
parece à primeira vista: quase sempre os sistemas de arquivos são montados em diretórios 
vazios.) Se um sistema contém vários discos rígidos, todos eles também podem ser montados 
em uma única árvore. 

Outro conceito importante no MINIX 3 é o de arquivo especial. Os arquivos especiais 
são fornecidos para fazer os dispositivos de E/S se comportarem como se fossem arquivos 
convencionais. Desse modo, eles podem ser lidos e escritos usando as mesmas chamadas de 
sistema que são usadas para ler e escrever arquivos. Existem dois tipos de arquivos especiais: 
arquivos especiais de bloco e arquivos especiais de caractere. Os arquivos especiais de 
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bloco normalmente são usados para modelar dispositivos que consistem em um conjunto de 
blocos endereçáveis aleatoriamente, como os discos. Abrindo um arquivo especial de bloco 
e lendo, digamos, o bloco 4, um programa pode acessar diretamente o quarto bloco no dis- 
positivo, sem considerar a estrutura do sistema de arquivos nele contida. Analogamente, os 
arquivos especiais de caractere são usados para modelar impressoras, modems e outros dispo- 
sitivos que aceitam ou geram como saída um fluxo de caracteres. Por convenção, os arquivos 
especiais são mantidos no diretório /dev (de device — dispositivo, em inglês). Por exemplo, 
/dev/lp seria a impressora de linha. 

O último recurso que discutiremos nesta visão geral está relacionado tanto com pro- 
cessos como com arquivos: os pipes. Um pipe é uma espécie de pseudo-arquivo que pode 
ser usado para conectar dois processos, como se vê na Figura 1-8. Se os processos 4 e B 
quiserem se comunicar usando um pipe, eles devem configurá-lo antecipadamente. Quando 
o processo A quer enviar dados para o processo B, ele escreve no pipe como se fosse um 
arquivo de saída. O processo B pode ler os dados do pipe como se ele fosse um arquivo de 
entrada. Assim, a comunicação entre processos no MINIX 3 é muito parecida com as leituras 
e escritas normais em arquivos. Além de tudo, a única maneira pela qual um processo pode 
descobrir se o arquivo de saída em que está escrevendo não é realmente um arquivo, mas um 
pipe, é fazendo uma chamada de sistema especial. 


Processo Processo 
Pipe 


Figura 1-8 Dois processos conectados por um pipe. 


O shell 


O sistema operacional é o código que executa as chamadas de sistema. Os editores, compi- 
ladores, montadores, ligadores e interpretadores de comandos não fazem parte do sistema 
operacional, ainda que sejam importantes e úteis. Correndo o risco de confundir um pouco as 
coisas, nesta seção veremos brevemente o interpretador de comandos do MINIX 3, chamado 
de shell. Embora não faça parte do sistema operacional, ele faz uso pesado de muitos recursos 
do sistema operacional e, portanto, serve como um bom exemplo de como as chamadas de 
sistema podem ser empregadas. Ele também é a principal interface entre um usuário sentado 
diante de seu terminal e o sistema operacional, a não ser que o usuário esteja utilizando uma 
interface gráfica. Existem muitos shells, incluindo csh, ksh, zsh e bash. Todos eles suportam 
a funcionalidade descrita a seguir, a qual é derivada do shell original (sh). 

Quando um usuário se conecta, um shell é iniciado. O shell tem o terminal como en- 
trada e saída padrão. Ele começa apresentando o prompt normalmente um caractere como 
o cifrão, que informa ao usuário que o shell está esperando para aceitar comandos. Se agora 
o usuário digitar 


date 


por exemplo, o shell criará um processo filho e executará o programa date como filho. En- 
quanto o processo filho está em execução, o shell espera que ele termine. Quando o filho 
termina, o shell exibe novamente o prompt e tenta ler a próxima linha de entrada. 

O usuário pode especificar que a saída padrão seja redirecionada para um arquivo, por 
exemplo, 


date >file 
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Analogamente, a entrada padrão pode ser redirecionada, como em 
sort <file1 >file2 


que ativa o programa sort com a entrada extraída de file] e a saída enviada para file2. 
A saída de um programa pode ser usada como entrada de outro, conectando-as com um 
pipe. Assim, 


cat file 1 file2 file3 | sort >/dev/lp 


executa o programa cat para concatenar três arquivos e enviar a saída para sort a fim de clas- 
sificar todas as linhas em ordem alfabética. A saída de sort é redirecionada para o arquivo 
/dev/lp, normalmente uma a impressora. 

Se um usuário colocar o caractere & após um comando, o shell não esperará que ele 
termine. Em vez disso, ele fornecerá um prompt imediatamente. Consegiientemente, 


cat file 1 file2 file3 | sort >/dev/lp & 


inicia o programa sort como uma tarefa de segundo plano (background), permitindo que o 
usuário continue a trabalhar normalmente, enquanto o programa sort está em execução. O shell 
tem vários outros recursos interessantes para os quais não dispomos de espaço para discutir 
aqui. A maioria dos livros para iniciantes no UNIX serve para usuários do MINIX 3 que quei- 
ram aprender mais sobre o uso do sistema. Exemplos são Ray e Ray (2003) e Herborth (2005). 


CHAMADAS DE SISTEMA 


Munidos de nosso conhecimento geral sobre como o MINIX 3 lida com processos e arqui- 
vos, podemos agora começar a ver a interface entre o sistema operacional e seus programas 
aplicativos; isto é, o conjunto de chamadas de sistema. Embora esta discussão se refira espe- 
cificamente ao POSIX (International Standard 9945-1) e, portanto, também ao MINIX 3, ao 
UNIX e ao Linux, a maioria dos outros sistemas operacionais modernos tem chamadas de 
sistema que executam as mesmas funções, ainda que alguns detalhes sejam diferentes. Como 
a mecânica de uma chamada de sistema depende muito da máquina, e fregiientemente deve 
ser expressa em código assembly, é fornecida uma biblioteca de funções para tornar possível 
fazer chamadas de sistema a partir de programas escritos em C. 

É interessante ter o seguinte em mente: qualquer computador com apenas uma CPU 
pode executar apenas uma instrução por vez. Se um processo estiver executando um pro- 
grama no modo usuário e precisar de um serviço do sistema, como a leitura de dados de um 
arquivo, ele terá de executar uma instrução de interrupção, ou de chamada de sistema, para 
transferir o controle para o sistema operacional. O sistema operacional descobre o que o pro- 
cesso que fez a chamada deseja inspecionando um conjunto de parâmetros. Em seguida, ele 
executa a chamada de sistema e retorna o controle para a instrução que está depois da chama- 
da de sistema. De certo modo, fazer uma chamada de sistema é como fazer um tipo especial 
de chamada de função, somente que as chamadas de sistema entram no núcleo, ou em outros 
componentes privilegiados do sistema operacional, e as chamadas de função não. 

Para tornar o mecanismo de chamada de sistema mais claro, vamos examinar breve- 
mente a chamada read. Ela tem três parâmetros: o primeiro especificando o arquivo, o segun- 
do especificando um buffer e o terceiro especificando o número de bytes a serem lidos. Uma 
chamada para read a partir de um programa em C poderia ser como segue: 


count = read(fd, buffer, nbytes); 
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A chamada de sistema (e a função de biblioteca) retorna o número de bytes realmente 
lidos em count. Normalmente, esse valor é igual ao de nbytes, mas pode ser menor, se, por 
exemplo, o fim do arquivo for encontrado durante a leitura. 

Se a chamada de sistema não puder ser executada, seja devido a um parâmetro inválido 
ou a um erro do disco, count será configurado como -1 e o número indicando o código do 
erro será colocado em uma variável global, errno. Os programas sempre devem verificar os 
resultados de uma chamada de sistema para ver se ocorreu um erro. 

O MINIX 3 tem um total de 53 chamadas de sistema principais. Elas estão listadas 
na Figura 1-9, agrupadas, por conveniência, em seis categorias. Existem algumas outras 
chamadas, mas são de uso muito especializado, de modo que vamos omiti-las aqui. Nas 
seções a seguir, examinaremos brevemente cada uma das chamadas da Figura 1-9 para ver o 
que elas fazem. De maneira geral, os serviços oferecidos por essas chamadas determinam a 
maior parte do que o sistema operacional tem de fazer, pois o gerenciamento de recursos nos 
computadores pessoais é mínimo (pelo menos comparado com as máquinas de maior porte, 
com muitos usuários). 

Este é um bom lugar para mencionar que o mapeamento de chamadas de função do 
POSIX para as chamadas de sistema não é necessariamente biunívoco. O padrão POSIX es- 
pecifica várias funções que um sistema compatível deve fornecer, mas não especifica se elas 
são chamadas de sistema, chamadas de biblioteca ou qualquer outra coisa. Em alguns casos, 
as funções do POSIX são suportadas como rotinas de biblioteca no MINIX 3. Em outros, 
diversas funções práticas são apenas pequenas variações umas das outras, e uma chamada de 
sistema trata de todas elas. 


Chamadas de sistema para gerenciamento de processos 


O primeiro grupo de chamadas de sistema da Figura 1-9 trata com o gerenciamento de 
processos. Fork é um bom lugar para começar a discussão. Fork é a única maneira de 
criar um novo processo no MINIX 3. Ele cria uma duplicata exata do processo original, 
incluindo todos os descritores de arquivo, registradores-tudo. Depois de fork, o processo 
original e a cópia (o pai e o filho) seguem caminhos diferentes. Todas as variáveis têm 
valores idênticos no momento do fork, mas como os dados do pai são copiados para criar 
o filho, as alterações subsequentes em um deles não afetam o outro. (O texto do programa, 
que é imutável, é compartilhado entre pai e filho.) A chamada de fork retorna um valor, que 
é zero no filho e igual ao identificador de processo, ou PID (Process IDentifier) do filho 
no pai. Usando o PID retornado, os dois processos podem ver qual deles é o processo pai 
e qual é o processo filho. 

Na maioria dos casos, após um fork, o filho precisará executar um código diferente do 
pai. Considere o caso do shell. Ele lê um comando do terminal, cria um processo filho, espera 
que o filho execute o comando e depois, quando o filho termina, lê o comando seguinte. Para 
esperar o filho terminar, o pai executa uma chamada de sistema waitpid, a qual apenas espera 
até que o filho termine (qualquer filho, se existir mais de um). Waitpid pode esperar por um 
filho específico ou, configurando o primeiro parâmetro como -1, por qualquer filho. Quando 
waitpid terminar, o endereço apontado pelo segundo parâmetro, statloc, será configurado com 
o status de saída do filho (término normal ou anormal e o valor de saída). Várias opções tam- 
bém são fornecidas, especificadas pelo terceiro parâmetro. A chamada de waitpid substitui a 
chamada de wait, que agora é obsoleta, mas fornecida por motivos de compatibilidade com 
versões anteriores. 

Considere agora como fork é usado pelo shell. Quando um comando é digitado, o shell 
cria um novo processo. Esse processo filho deve executar o comando do usuário. Ele faz isso 
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pid = fork() 


Cria um processo filho idêntico ao pai 


processos pid = waitpid(pid, &statloc, opts) Espera que um filho termine 
s = wait(&status) Versão antiga de waitpid 
s = execve(name, argv, envp) Substitui a imagem do núcleo de um processo 
exit(status) Termina a execução do processo e retorna o status 
size = brk(addr) Define o tamanho do segmento de dados 
pid = getpid() Retorna a identificação do processo que fez a chamada 
pid = getpgrp() Retorna a identificação do grupo do processo que fez a 
chamada 
pid = setsid() Cria uma nova sessão e retorna a identificação de seu grupo 
de processo 
l = ptrace(reg, pid, addr, data) Usado para depuração 
Sinais s = sigaction(sig, &act, &oldact) Define a ação a ser executada nos sinais 


s = sigreturn(&context) 

s = sigprocmask(how, &set, &old) 
s = sigpending(set) 

s = sigsuspend(sigmask) 

s = kill(pid, sig) 

residual = alarm(seconds) 

s = pause() 


Retorna de um tratamento de sinal 

Examina ou altera a máscara do sinal 

Obtém o conjunto de sinais bloqueados 

Substitui a máscara do sinal e suspende o processo 

Envia um sinal para um processo 

Configura um temporizador 

Suspende o processo que fez a chamada até o próximo sinal 


Gerenciamento de 
arquivos 


fd = creat(name, mode) 

fd = mknod(name, mode, addr) 
fd = open(file, how, ...) 

s = close(fd) 

n = read(fd, buffer, nbytes) 

n = write(fd, buffer, nbytes) 
pos = Iseek(fd, offset, whence) 
s = stat(name, &buf) 

s = fstat(fd, &buf) 

fd = dup(fd) 

s = pipe(&fd[0]) 

s = joctI(fd, request, argp) 

s = access(name, amode) 

s = rename(old, new) 

s = fenti(fd, cmd, ...) 


Modo obsoleto de criar um novo arquivo 

Cria um i-node normal, especial ou de diretório 
Abre um arquivo para leitura, escrita ou ambos 
Fecha um arquivo aberto 

Lê dados de um arquivo para um buffer 
Escreve dados de um buffer em um arquivo 
Move o ponteiro de arquivo 

Obtém informações de status de um arquivo 
Obtém informações de status de um arquivo 
Aloca um novo descritor de arquivo para um arquivo aberto 
Cria um pipe 

Executa operações especiais em um arquivo 
Verifica a acessibilidade de um arquivo 

Atribui um novo nome a um arquivo 
Travamento de um arquivo e outras operações 


Gerenciamento de 
diretórios e do sistema 
de arquivos 


s = mkdir(name, mode) 

s = rmdir(name) 

s = link(namel, name2) 

s = unlink(name) 

s = mount(special, name, flag) 
s = umount(special) 

s = sync() 

s = chdir(dirname) 

s = chroot(dirname) 


Cria um novo diretório 

Remove um diretório vazio 

Cria uma nova entrada, name2, apontando para namel 
Remove uma entrada de diretório 

Monta um sistema de arquivos 

Desmonta um sistema de arquivos 

Transfere todos os blocos da cache para o disco 

Muda o diretório de trabalho 

Muda o diretório-raiz 


Proteção 


s = chmod(name, mode) 

uid = getuid() 

gid = getgid() 

s = setuid(uid) 

s = setgid(gid) 

s = chown(name, owner, group) 
oldmask = umask(complmode) 


Altera os bits de proteção de um arquivo 
Obtém a uid do processo que fez a chamada 
Obtém a gid do processo que fez a chamada 
Configura a uid do processo que fez a chamada 
Configura a gid do processo que fez a chamada 
Altera o proprietário e o grupo de um arquivo 
Altera a máscara de modo 


Gerenciamento de 
tempo 


seconds = time(&seconds) 
s = stime(tp) 

s = utime(file, timep) 

s = times(buffer) 


Obtém o tempo decorrido desde 1° de janeiro de 1970 
Configura o tempo decorrido desde 1° de janeiro de 1970 
Configura o momento do “último acesso” de um arquivo 
Obtém os tempos do usuário e do sistema usados até o 
momento 


Figura 1-9 As principais chamadas de sistema do MINIX. ( fd é um descritor de arquivo; n é uma quan- 


tidade de bytes.) 
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usando a chamada de sistema execve, que faz sua imagem de núcleo inteira ser substituída 
pelo arquivo nomeado dado por seu primeiro parâmetro. (Na verdade, a chamada de sistema 
em si é exec, mas várias bibliotecas de funções distintas a chamam com parâmetros e nomes 
ligeiramente diferentes. As trataremos aqui como chamadas de sistema.) Um shell extrema- 
mente simplificado, ilustrando o uso de fork, waitpid e execve, aparece na Figura 1-10. 


tidefine TRUE 1 


while (TRUE) ( /* repete indefinidamente */ 

type prompt(); /* exibe o prompt na tela */ 
read command(command, parameters); /* Iê a entrada do terminal */ 
if (fork() != 0) ( /* cria processo filho */ 

/* Código do pai. */ 

waitpid(-1, &status, 0); /* espera o filho terminar */ 
else { 

/* Código do filho. */ 

execve(command, parameters, 0); /* executa o código command */ 
} 


} 
Figura 1-10 Um shell simplificado. Neste livro, supõe-se que TRUE seja definido como 1. 


No caso mais geral, execve tem três parâmetros: o nome do arquivo a ser executado, 
um ponteiro para o array de argumentos e um ponteiro para o array de ambiente. Eles serão 
descritos em breve. Várias rotinas de biblioteca, incluindo execl, execv, execle e execve, são 
fornecidas para permitir que os parâmetros sejam omitidos ou especificados de diversas ma- 
neiras. Neste livro, usaremos o nome exec para representar a chamada de sistema ativada por 
todas elas. 

Vamos considerar o caso de um comando como 


cp file1 file2 


usado para copiar file] em file2. O shell cria um processo filho que localiza e executa o arqui- 
vo cp e passa para ele os nomes dos arquivos de origem e de destino. 

O programa principal de cp (e o programa principal da maioria dos outros programas 
em C) contém a declaração 


main(argc, argv, envp) 


onde argc é o número de elementos da linha de comando, incluindo o nome do programa. 
Para o exemplo anterior, argc é 3. 

O segundo parâmetro, argv, é um ponteiro para um array. O elemento i desse array 
é um ponteiro para a i-ésima string” na linha de comando. Em nosso exemplo, argv[0] 
apontaria para a string “cp”, argv[1] apontaria para a string “filel” e argv[2] apontaria para 
a string “file2”. 

O terceiro parâmetro de main, envp, é um ponteiro para o ambiente, um array de strings 
contendo atribuições da forma nome=valor, usadas para passar informações para um progra- 


* N. de R. T.: String (cadeia) é uma estrutura de dados composta por uma série de caracteres, geralmente contendo um texto 
legível e inteligível pelas pessoas. 
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ma, como o tipo de terminal e o nome do diretório de base. Na Figura 1-10, nenhum ambiente 
é passado para o filho, de modo que o terceiro parâmetro de execve é zero. 

Se exec parece complicado, não se desespere; essa é (semanticamente) a mais com- 
plexa de todas as chamadas de sistema do POSIX. Todas as outras são muito mais simples. 
Como exemplo de uma chamada simples, considere exit, que os processos devem usar ao 
terminarem sua execução. Ela tem um único parâmetro, o status de saída (de O a 255), que 
é retornado para o pai por meio de statloc na chamada de sistema waitpid. O byte de ordem 
inferior de status contém o status do término, sendo O o término normal e os outros valores 
sendo diversas condições de erro. O byte de ordem superior contém o status de saída do filho 
(de 0 a 255). Por exemplo, se um processo pai executar a instrução 


n = waitpid(-1, &statloc, options); 


ele será suspenso até que algum processo filho termine. Se o filho sair com, digamos, 4 como 
parâmetro para exit, o pai será ativado com n configurado como o PID do filho e statloc confi- 
gurado como 0x0400 (a convenção da linguagem C de prefixar constantes hexadecimais com 
Ox será usada neste livro). 

No MINIX 3, os processos têm sua memória dividida em três segmentos: o segmento 
de texto (isto é, o código do programa), o segmento de dados (isto é, as variáveis do progra- 
ma) e o segmento de pilha. O segmento de dados cresce para cima e a pilha cresce para bai- 
xo, como mostrado na Figura 1-11. Entre eles há um intervalo de espaço de endereçamento 
não utilizado. A pilha aumenta de tamanho automaticamente, conforme for necessário, mas o 
aumento do segmento de dados é feito explicitamente por meio de uma chamada de sistema, 
brk, que especifica o novo endereço onde o segmento de dados deve terminar. Esse endereço 
pode ser maior do que o valor corrente (o segmento de dados está aumentando) ou menor do 
que o valor corrente (o segmento de dados está diminuindo). O parâmetro deve, é claro, ser 
menor do que o ponteiro da pilha, senão os segmentos de dados e de pilha iriam se sobrepor, 
o que é proibido. 


Endereço (hexadecimal) 
FFFF 


Figura 1-11 Os processos têm três segmentos: texto, dados e pilha. Neste exemplo, os três 
estão em um espaço de endereçamento, mas também é válido um espaço de instrução e de 
dados separados. 


Por conveniência aos programadores, é fornecida uma rotina de biblioteca sbrk que 
também muda o tamanho do segmento de dados, só que seu parâmetro é o número de bytes a 
serem adicionados no segmento de dados (parâmetros negativos tornam o segmento de dados 
menor). Ela funciona acompanhando o tamanho atual do segmento de dados, que é o valor re- 
tornado por brk, calculando o novo tamanho e fazendo uma chamada solicitando esse número 
de bytes. Entretanto, as chamadas de brk e sbrk não são definidas pelo padrão POSIX. Os 
programadores devem usar a função de biblioteca malloc para alocar área de armazenamento 
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1.4.2 


dinamicamente e a sua implementação interna não foi considerada um assunto conveniente 
para padronização. 

A próxima chamada de sistema de processo, getpid, também é simples. Ela apenas re- 
torna o PID do processo que fez a chamada. Lembre-se de que, em fork, somente o pai recebia 
o PID do filho. Se o filho quiser descobrir seu próprio PID, deverá usar getpid. A chamada de 
getpgrp retorna o PID do grupo do processo que fez a chamada. A chamada de setsid cria uma 
nova sessão e configura o PID do grupo como o do processo que fez a chamada. As sessões 
estão relacionadas a um recurso opcional do POSIX, chamado controle de jobs (job control), 
que não é suportado pelo MINIX 3 e com o qual não nos ocuparemos mais neste livro. 

A última chamada de sistema de gerenciamento de processos, ptrace, é utilizada por 
programas de depuração, para controlar o programa que está sendo depurado. Ela permite 
que o depurador leia e escreva a memória do processo controlado e a gerencie de outras 
maneiras. 


Chamadas de sistema para sinais 


Embora a maioria das formas de comunicação entre processos seja planejada, existem situa- 
ções nas quais é necessária uma comunicação inesperada. Por exemplo, se um usuário instrui 
acidentalmente um editor de textos a listar o conteúdo inteiro de um arquivo muito longo 
e depois percebe o erro, é necessário algum modo de interromper o editor. No MINIX 3, o 
usuário pode pressionar as teclas CTRL-C no teclado, o que envia um sinal para o editor. O 
editor recebe o sinal e interrompe a saída. Os sinais também podem ser usados para informar 
sobre certas interrupções detectadas pelo hardware, como uma instrução inválida ou estou- 
ro de ponto flutuante (overflow). Os tempos limites (timeouts) também são implementados 
como sinais. 

Quando um sinal é enviado para um processo que não anunciou seu desejo de aceitá-lo, 
o processo é simplesmente eliminado sem maiores alardes. Para evitar essa condição, um pro- 
cesso pode usar a chamada de sistema sigaction para anunciar que está preparado para aceitar 
algum tipo de sinal para fornecer o endereço de uma rotina de tratamento de sinal e um local 
para armazenar o endereço de execução da rotina atual. Após uma chamada de sigaction, se 
um sinal do tipo relevante for gerado (por exemplo, pelo pressionamento de CTRL-C), o es- 
tado do processo será colocado em sua própria pilha e, então, a rotina de tratamento de sinal 
será chamada. Ela pode ficar em execução por quanto tempo quiser e realizar as chamadas de 
sistema que desejar. Na prática, contudo, as rotinas de tratamento de sinal normalmente são 
bastante curtas. Quando a rotina de tratamento de sinal termina, ela chama sigreturn para que 
a execução continue a partir de onde parou, antes do sinal. A chamada de sigaction substitui a 
chamada signal, mais antiga, que agora é fornecida como uma função de biblioteca por com- 
patibilidade com versões anteriores. 

No MINIX 3, os sinais podem ser bloqueados. Um sinal bloqueado fica pendente até 
ser desbloqueado. Ele não é enviado, mas também não é perdido. A chamada de sigprocmask 
permite que um processo defina o conjunto de sinais a serem bloqueados apresentando ao 
núcleo um mapa de bits. Também é possível um processo solicitar o conjunto de sinais pen- 
dentes, mas que não podem ser enviados por estarem bloqueados. A chamada de sigpending 
retorna esse conjunto como um mapa de bits. Finalmente, a chamada de sigsuspend que 
permite a um processo configurar de forma atômica o mapa de bits dos sinais bloqueados e 
suspender a si mesmo. 

Em vez de fornecer uma função para capturar um sinal, o programa também pode espe- 
cificar a constante SIG IGN para ignorar todos os sinais subsequentes do tipo especificado, 
ou SIG DFL para restaurar a ação padrão do sinal, quando ele ocorrer. A ação padrão é eli- 
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minar o processo, ou ignorar o sinal, dependendo do sinal. Como exemplo de como SIG IGN 
é usado, considere o que acontece quando o shell cria um processo de segundo plano como 
resultado de 


command & 


Seria indesejável que um sinal SIGINT (gerado pelo pressionamento de CTRL-C) afe- 
tasse o processo de segundo plano; portanto, após fork, mas antes de exec, o shell faz 


sigaction(SIGINT, SIG IGN, NULL); 


sigaction(SIGQUIT, SIG IGN, NULL); 


para desativar os sinais SIGINT e SIGQUIT. (SIGQUIT é gerado por CTRL; que é igual ao 
sinal SIGINT gerado por CTRL-C, exceto que, se ele não for capturado ou ignorado, acarre- 
tará um core dump* do processo eliminado.) Para processos de primeiro plano (foreground), 
aqueles lançados sem o uso do “&”, esses sinais não são ignorados. 

Pressionar CTRL-C não é a única maneira de enviar um sinal. A chamada de sistema 
kill permite que um processo sinalize outro processo (desde que eles tenham o mesmo UID 
— processos não relacionados não podem sinalizar um ao outro). Voltando ao exemplo dos 
processos de segundo plano usado anteriormente, suponha que um processo de segundo pla- 
no seja iniciado, mas que posteriormente decida-se que o processo deve ser terminado. SI- 
GINT e SIGQUIT foram desativados; portanto, algo mais é necessário. A solução é utilizar o 
programa kill, que usa a chamada de sistema kill para enviar um sinal para qualquer processo. 
Enviando-se o sinal 9 (SIGKILL) para um processo de segundo plano, esse processo é elimi- 
nado. SIGKILL não pode ser capturado nem ignorado. 

Para muitas aplicações de tempo real, um processo precisa ser interrompido, após um 
intervalo de tempo específico, para fazer algo, como retransmitir um pacote possivelmente 
perdido em um meio de comunicação não confiável. Para tratar dessa situação, foi definida a 
chamada de sistema alarm. O parâmetro especifica um intervalo de tempo, em segundos, após 
o qual um sinal SIGALRM é enviado para o processo. Um processo pode ter apenas um alar- 
me pendente em dado instante. Se for feita uma chamada de alarm com um parâmetro de 10 
segundos e, então, 3 segundos mais tarde, for feita outra chamada de alarm com um parâme- 
tro de 20 segundos, somente um sinal será gerado, 20 segundos após a segunda chamada. O 
primeiro sinal é cancelado pela segunda chamada de alarm. Se o parâmetro de alarm for zero, 
qualquer sinal de alarme pendente será cancelado. Se um sinal de alarme não for capturado, a 
ação padrão será executada e o processo sinalizado será eliminado. 

Às vezes, ocorre que um processo não tem nada para fazer até a chegada de um sinal. 
Por exemplo, considere um programa de ensino auxiliado por computador que está testando 
a velocidade e a compreensão da leitura. Ele mostra um texto na tela e depois chama alarm 
para sinalizá-lo após 30 segundos. Enquanto o aluno está lendo o texto, o programa não tem 
nada para fazer. Ele poderia entrar em um laço sem fazer nada, mas isso desperdiçaria tempo 
da CPU que outro processo ou usuário talvez precisasse. Uma idéia melhor é usar pause, que 
instrui o MINIX 3 a suspender o processo até o próximo sinal. 


* N. de R. T.: Core dump é a imagem do espaço de endereçamento de um processo em um determinado instante de tempo. Nor- 
malmente, essa imagem é empregada por ferramentas de depuração de programas. 
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1.4.3 Chamadas de sistema para gerenciamento de arquivos 


Muitas chamadas de sistema estão relacionadas com o sistema de arquivos. Nesta seção, 
veremos as chamadas que operam sobre arquivos individuais; na próxima, examinaremos as 
que envolvem diretórios ou o sistema de arquivos como um todo. Para criar um arquivo novo, 
é usada a chamada creat (o motivo pelo qual a chamada é creat e não create se perdeu no pas- 
sar do tempo). Seus parâmetros fornecem o nome do arquivo e o modo de proteção. Assim 


fd = creat(“abc”, 0751); 


cria um arquivo chamado abc com o modo 0751 octal (na linguagem C, um zero inicial sig- 
nifica que uma constante está em octal). Os 9 bits de ordem inferior da constante 0751 espe- 
cificam os bits rwx do proprietário (7 significa permissão de leitura-escrita-execução), de seu 
grupo (5 significa leitura-execução) e outros (1 significa somente execução). 

Creat não apenas cria um novo arquivo, mas também o abre para escrita, independente- 
mente do modo do arquivo. O descritor de arquivo retornado, fd, pode ser usado para escrever 
no arquivo. Se creat for usado sobre um arquivo já existente, esse arquivo será truncado no 
comprimento 0, desde que, é claro, todas as permissões estejam corretas. A chamada de creat 
é obsoleta, pois agora open pode criar novos arquivos, mas foi incluída por compatibilidade 
com versões anteriores. 

Arquivos especiais são criados usando-se mknod, em vez de creat. Uma chamada tí- 
pica é 


fd = mknod(“/dev/ttyc2”, 020744, 0x0402); 


a qual cria um arquivo chamado /dev/ttyc2 (o nome usual do console 2) e atribui a ele o modo 
02744 octal (um arquivo de caracteres especial com bits de proteção rwxr--r--). O terceiro pa- 
râmetro contém o tipo de dispositivo (major device number) no byte de ordem superior, 0x04, 
nesse exemplo, e a identificação de uma unidade específica (minor device number) desse 
mesmo tipo de dispositivo é dada no byte de ordem inferior, 0x02, no caso. O tipo do disposi- 
tivo poderia ser qualquer um, mas um arquivo chamado /dev/ttyc2 deve ser sempre associado 
ao dispositivo 2. As chamadas de mknod falham, a não ser que seja feita pelo superusuário. 

Para ler ou escrever um arquivo existente, primeiramente o arquivo deve ser aberto 
com open. Essa chamada especifica o arquivo a ser aberto através um nome de caminho ab- 
soluto ou de um nome relativo ao diretório de trabalho corrente, e os códigos O RDONLY, 
O WRONLY ou O RDWR, significam abertura somente para leitura, somente para escrita ou 
ambos. O descritor de arquivo retornado pode então ser usado para operações posteriores de 
leitura ou escrita. Depois, o arquivo é fechado com a chamada de sistema close, o que libera 
o descritor de arquivo disponível para ser reaproveitado por uma chamada creat ou open 
subsegiiente. 

As chamadas mais utilizadas são, sem dúvida, read e write. Vimos read anteriormente; 
a chamada write tem os mesmos parâmetros. 

Embora a maioria dos programas leia e escreva arquivos em segiiência, para algumas 
aplicações os programas precisam acessar aleatoriamente qualquer parte de um arquivo. Asso- 
ciado a cada arquivo existe um ponteiro indicando a posição corrente de acesso. Ao se ler (es- 
crever) em segiiência, ele normalmente aponta para o próximo byte a ser lido (escrito). A cha- 
mada de Iseek altera o valor do ponteiro de posição, de modo que as chamadas subsequentes 
para read ou write podem começar em qualquer ponto no arquivo ou mesmo além do final. 

Iseek tem três parâmetros: o primeiro é o descritor de arquivo, o segundo é a ponteiro 
de posição e o terceiro informa se essa posição é relativa ao início dele, à posição atual ou ao 
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final do arquivo. O valor retornado por Iseek é a posição absoluta no arquivo depois de alterar 
a posição do ponteiro. 

Para cada arquivo, o MINIX 3 monitora o modo do arquivo (arquivo normal, arquivo 
especial, diretório etc.), o tamanho, o momento da última modificação e outras informações. 
Os programas podem pedir para ver essas informações por meio das chamadas de sistema 
stat e fstat. Elas diferem apenas porque a primeira especifica o arquivo pelo nome, enquanto a 
última recebe um descritor de arquivo, o que a torna útil para arquivos abertos, especialmente 
de entrada e saída padrão, cujos nomes podem não ser conhecidos. As duas chamadas forne- 
cem como segundo parâmetro um ponteiro para uma estrutura onde as informações devem 
ser colocadas. A estrutura aparece na Figura 1-12. 


struct stat ( 


short st dev; /* dispositivo ao qual o i-node pertence */ 
unsigned short st ino; /* número do i-node */ 

unsigned short st mode; /* modo palavra */ 

short st nlink; /* número de vínculos */ 

short st uid; /* id do usuário */ 

short st_gid; /* id do grupo */ 

short st_rdev; /* major/minor device para arquivos especiais */ 
long st_size; /* tamanho do arquivo */ 

long st_atime; /* horário do último acesso */ 

long st_mtime; /* horário da última modificação */ 

long st_ctime; /* horário da última alteração no i-node */ 


k 


Figura 1-12 A estrutura usada para retornar informações das chamadas de sistema stat e 
fstat. No código real, são utilizados nomes simbólicos para alguns tipos. 


A chamada de sistema dup é útil ao se manipular descritores de arquivo. Considere, por 
exemplo, um programa que precisa fechar a saída padrão (descritor de arquivo 1), substituí- 
la por outro arquivo qualquer, chamar uma função que escreve uma saída qualquer nesse 
arquivo e, então, restaurar a situação original. Apenas fechar o descritor de arquivo 1 e depois 
abrir um novo arquivo transformará este último na nova saída padrão, mas será impossível 
restaurar a situação original. 

A solução, nesse caso, é executar primeiro a instrução 


fd = dup(1); 


que utiliza a chamada de sistema dup para alocar um novo descritor de arquivo, fd, e provi- 
denciar para que ele corresponda ao mesmo arquivo da saída padrão. Então, a saída padrão 
pode ser fechada e um novo arquivo pode ser aberto e utilizado. Quando chegar o momento 
de restaurar a situação original, o descritor de arquivo 1 pode ser fechado e, então 


n = dup (fd); 


executado para atribuir o descritor de arquivo mais baixo, a saber, 1, para o mesmo arquivo 
apontado por fd. Finalmente, fd pode ser fechado e voltamos ao ponto inicial. 

A chamada dup tem uma variante que permite a um descritor de arquivo arbitrário não 
inicializado referenciar um determinado arquivo aberto. Ela é chamada por 


dup2(fd, fd2); 
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onde fd se refere a um arquivo aberto e fd2 é o descritor de arquivo não inicializado que 
referenciará o mesmo arquivo que fd. Assim, se fd aponta para a entrada padrão (descritor 
de arquivo 0) e fd2 for 4, após a chamada, os descritores de arquivo O e 4 irão apontar para a 
entrada padrão. 

No MINIX 3, a comunicação entre processos usa pipes, conforme descrito anteriormen- 
te. Quando um usuário digita 


cat file 1 file2 | sort 


o shell cria um pipe e faz com que a saída padrão do primeiro processo escreva no pipe e 
que a entrada padrão do segundo processo leia a partir dele. A chamada de sistema pipe 
cria um pipe e retorna dois descritores de arquivo, um para leitura e outro para escrita. A 
chamada é 


pipe (8fd[0]); 


onde fd é um array de dois números inteiros, fd[0] é o descritor de arquivo para leitura e fd[1] 
para escrita. Geralmente, é feito um fork logo após a chamada pipe, o processo pai fecha o 
descritor de arquivo para leitura e o processo filho fecha o descritor de arquivo para escrita 
(ou vice-versa), de modo que um processo possa ler no pipe e que o outro escrever nele. 

A Figura 1-13 representa um esqueleto de programa que cria dois processos, com a 
saída do primeiro canalizada (piped) para o segundo. (Um exemplo mais realista deveria 
fazer a verificação de erro e tratar os argumentos.) Primeiro, o pipe é criado e o processo 
executa um fork fazendo com que o processo pai se torne o primeiro processo do pipe e o pro- 
cesso filho o segundo. Como os arquivos a serem executados, process! e process2, não sabem 


tdefine STD INPUTO /* descritor de arquivo da entrada padrão */ 
Hdefine STD OUTPUT 1 /* descritor de arquivo da saída padrão */ 
pipeline(process1, process2) 
char *process1, *process2; /* ponteiros para nomes de programa */ 
{ 
int fd[2]; 
pipe(&fd[0]); /* cria um pipe */ 
if (fork() != 0) { 
/* O processo pai executa estes comandos. */ 
close(fd[0]); /* o processo 1 não precisa ler o pipe */ 
close(STD OUTPUT); /* prepara a nova saída padrão */ 
dup(fd[1]); /* configura a saída padrão como fd[1] */ 
close(fd[1]); /* este descritor de arquivo não é mais necessário */ 
execi(process1, process1, 0); 
else { 
/* O processo filho executa estes comandos. */ 
close(fd[1]); /* o processo 2 não precisa escrever no pipe */ 
close(STD INPUT); /* prepara a nova entrada padrão */ 
dup(fd[0]); /* configura a entrada padrão como fd[0] */ 
close(fd[0]); /* este descritor de arquivo não é mais necessário */ 
execi(process2, process2, 0); 
} 


} 


Figura 1-13 Um esqueleto para configurar um canal de comunicação (pipe) entre dois pro- 
cessos. 
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que fazem parte de um pipe, é fundamental que os descritores de arquivo sejam tratados de 
modo que a saída padrão do primeiro processo e a entrada padrão do segundo processo sejam 
o pipe. O pai primeiro fecha o descritor de arquivo para leitura do pipe. A seguir, ele fecha a 
saída padrão e faz uma chamada de dup para permitir ao descritor de arquivo 1 escrever no 
pipe. É importante perceber que dup sempre retorna o descritor de arquivo mais baixo dispo- 
nível, neste caso, 1. Então, o programa fecha o outro descritor de arquivo do pipe. 

Após a chamada de exec, o processo pai terá os descritores de arquivo O e 2 inalterados, 
e o descritor de arquivo 1 para escrever no pipe. O código do processo filho é análogo. Os 
parâmetros de execl são repetidos porque o primeiro é o arquivo a ser executado e o segundo 
é o primeiro parâmetro, que a maioria dos programas espera que seja o nome do arquivo. 

A próxima chamada de sistema, ioctl, é potencialmente aplicada a todos os arquivos es- 
peciais. Ela é utilizada, por exemplo, por drivers de dispositivo de bloco como o driver SCSI 
para controlar dispositivos de fita e CD-ROM. Entretanto, seu uso principal é com arquivos 
de caractere especiais, principalmente terminais. O padrão POSIX define diversas funções 
que a biblioteca transforma em chamadas de ioctl. As funções de biblioteca tcgetattr e tcsetat- 
tr usam ioctl para alterar os caracteres utilizados para corrigir erros de digitação no terminal, 
para mudar o modo do terminal, etc. 

Tradicionalmente, existem três modos de terminal, processado, bruto e cbreak. O modo 
processado (cooked mode) é o modo terminal normal, no qual os caracteres de apagamento 
e de eliminação funcionam normalmente, CTRL-S e CTRL-Q podem ser usados para inter- 
romper e iniciar a saída do terminal, CTRL-D significa fim de arquivo, CTRL-C gera um 
sinal de interrupção e CTRLA gera um sinal para forçar um core dump. 

No modo bruto (raw mode) todas essas funções são desativadas; consegientemente, 
cada caractere é passado diretamente para o programa sem nenhum processamento especial. 
Além disso, no modo bruto, uma leitura a partir do terminal fornecerá para o programa todos 
os caracteres que foram digitados, mesmo uma linha parcial, em vez de esperar que uma 
linha completa seja digitada, como no modo processado. Os editores de tela frequentemente 
utilizam esse modo. 

O modo cbreak é um meio-termo. Os caracteres de apagamento e eliminação, como 
CTRL-D, são desativados para edição, mas CTRL-S, CTRL-Q, CTRL-C e CTRLA são ati- 
vados. Como no modo bruto, linhas parciais podem ser retornadas para os programas (se 
a edição de linhas estiver desativada, não haverá necessidade de esperar até que uma linha 
inteira seja recebida — o usuário não pode mudar de idéia e excluí-la, como acontece no modo 
processado). 

O POSIX não usa os termos processado, bruto e cbreak. Na terminologia do POSIX, 
o modo canônico corresponde ao modo processado. Nesse modo, existem 11 caracteres 
especiais definidos e a entrada é por linhas. No modo não-canônico, um número mínimo 
de caracteres a serem aceitos e um limite de tempo, definido em unidades de décimos de 
segundo, determinam como uma leitura será feita. No POSIX há muita flexibilidade e vários 
flags podem ser configurados para fazer o modo não-canônico comportar-se como modo 
cbreak ou modo bruto. Os termos antigos são mais descritivos e continuaremos a usá-los 
informalmente. 

ioctl tem três parâmetros; por exemplo, uma chamada para tcsetattr para configurar 
parâmetros do terminal resultará em 


ioctl (fd, TCSETS, &termios); 


O primeiro parâmetro especifica um arquivo, o segundo, uma operação e o terceiro é 
o endereço da estrutura do POSIX que contém os flags e o array de caracteres de controle. 
Outros códigos de operação instruem o sistema a adiar as alterações até que toda saída 
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tenha sido enviada, a fazer com que uma entrada não lida seja descartada e a retornar os 
valores correntes. 

A chamada de sistema access é utilizada para determinar se certo acesso a um arquivo é 
permitido pelo mecanismo de proteção. Ela é necessária porque alguns programas podem ser 
executados usando o UID de um usuário diferente. O mecanismo de SETUID será descrito 
posteriormente. 

A chamada de sistema rename permite dar um novo nome a um arquivo. Os parâmetros 
especificam o nome antigo e o novo. 

Finalmente, a chamada de sistema fcntl que é utilizada para arquivos de controle, mais 
ou menos análoga a ioctl (isto é, ambas são modificações mal feitas). Ela tem várias opções, 
sendo a mais importante o travamento (locking) de arquivos consultados por mais de uma 
aplicação. Usando fentl é possível para um processo travar e destravar partes de arquivos e 
testar se determinadas partes de um arquivo se encontram ou não travadas. A chamada não 
impõe nenhuma semântica para o travamento. Os programas devem fazer isso por si mesmo. 


Chamadas de sistema para gerenciamento de diretórios 


Nesta seção, veremos algumas chamadas de sistema que se relacionam mais com diretórios 
ou com o sistema de arquivos como um todo, em vez de apenas com um arquivo específico, 
como na seção anterior. As duas primeiras chamadas, mkdir e rmdir, criam e removem diretó- 
rios vazios, respectivamente. A chamada seguinte é link. Seu objetivo é permitir que o mesmo 
arquivo apareça com dois ou mais nomes, frequentemente em diretórios diferentes. Um uso 
típico é para permitir que vários membros de uma mesma equipe de programação comparti- 
lhem um arquivo comum, com o arquivo aparecendo no diretório próprio de cada um deles, 
possivelmente com nomes diferentes. Compartilhar um arquivo não é o mesmo que dar a 
cada membro da equipe uma cópia privativa, porque ter um arquivo compartilhado significa 
que as alterações feitas por qualquer membro da equipe são instantaneamente visíveis para 
os outros membros — existe apenas um arquivo. Quando são feitas cópias de um arquivo, as 
alterações subsegiientes feitas em uma cópia não afetam as outras. 

Para ver como a chamada de sistema link funciona, considere a situação da Figura 1- 
14(a). Lá, existem dois usuários, ast e jim, cada um tendo seus próprios diretórios com alguns 
arquivos. Se ast executar agora um programa contendo a chamada de sistema 


link(“/usr/jim/memo”, “/usr/ast/note”); 


o arquivo memo no diretório de jim será inserido no diretório de ast com o nome note. Depois 
disso, /usr/jim/memo e /usr/ast/note referem-se ao mesmo arquivo. Nesse caso, diz-se que há 
foi criado um vínculo (link) entre esses dois arquivos. 

Entender o funcionamento de link provavelmente tornará mais claro o que essa chamada 
faz. No UNIX, cada arquivo tem um número exclusivo, número-i, que o identifica. Esse nú- 
mero é um índice em uma tabela de i-nodes, um por arquivo, informando quem é o proprietá- 
rio do arquivo, onde estão seus blocos de disco etc. Um diretório é simplesmente um arquivo 
contendo um conjunto de pares (i-node, nome em ASCII). Nas primeiras versões do UNIX, 
cada entrada de diretório tinha 16 bytes — 2 bytes para o i-node e 14 bytes para o nome. Para 
dar suporte a nomes longos para os arquivos é preciso uma estrutura de dados mais com- 
plicada, mas conceitualmente um diretório ainda é um conjunto de pares (i-node, nome em 
ASCII). Na Figura 1-14, o i-node de mail é 16. O que link faz é simplesmente criar uma nova 
entrada de diretório com um nome (possivelmente novo), usando o i-node de um arquivo já 
existente. Na Figura 1-14(b), duas entradas têm o mesmo i-node (70) e, assim, referem-se 
ao mesmo arquivo. Se uma das duas for removida posteriormente, usando-se a chamada de 
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sistema unlink, a outra permanecerá. Se as duas forem removidas, o UNIX verá que não existe 
nenhuma entrada para o arquivo (um campo no i-node controla o número de entradas de dire- 
tório que apontam para o arquivo); portanto, o arquivo será removido do disco. 


lusr/ast /usr/jim lusr/ast /usr/jim 
16 | mail 31 | bin 
81 | games 70 | memo 81 | games 70 | memo 
40 | test 59 | f.c. 40 | test 59 | f.c. 
38 | progi 70 | note 38 | prog1 


(a) (b) 


Figura 1-14 (a) Dois diretórios antes de vincular /usr/jim/memo ao diretório de ast. (b) Os 
mesmos diretórios após o vínculo (link). 


Conforme mencionamos anteriormente, a chamada de sistema mount permite que dois 
sistemas de arquivos sejam combinados em um só. Uma situação comum é ter o sistema de 
arquivos-raiz, contendo as versões em binário (executáveis) dos comandos comuns, e outros 
arquivos intensamente utilizados em um disco rígido. O usuário pode então inserir um CD- 
ROM com os arquivos a serem lidos na respectiva unidade. 

Executando a chamada de sistema mount, o sistema de arquivos do CD-ROM pode ser 
integrado ao sistema de arquivos-raiz, como se vê na Figura 1-15. Uma instrução típica em C 
para realizar a montagem é 


mount(“/dev/cdromoO”, “/mnt”, 0); 


onde o primeiro parâmetro é o nome de um arquivo de bloco especial da unidade de CD-ROM 
0, o segundo parâmetro é o lugar na árvore onde ele deve ser montado e o terceiro indica se o 
sistema de arquivos deve ser montado para leitura e escrita ou somente para leitura. 


bin dev lib mnt usr DN 
(b) 


(a) 


Figura 1-15 (a) Sistema de arquivos antes da montagem. (b) Sistema de arquivos depois da 
montagem. 


Depois da chamada mount, um arquivo na unidade de CD-ROM O pode ser acessado 
usando-se apenas seu caminho a partir do diretório-raiz, ou do diretório de trabalho, sem 
considerar em qual unidade ele fisicamente está. Na verdade, a segunda, a terceira e a quarta 
unidades de disco também podem ser montadas em qualquer lugar na árvore. A chamada 
mount torna possível integrar mídia removível em uma única hierarquia de arquivos, sem a 
necessidade de se preocupar com o dispositivo em que um arquivo está. Embora este exemplo 
envolva CD-ROMs, discos rígidos ou partes de discos rígidos (freqüentemente chamadas de 
partições ou minor devices) também podem ser montados desta maneira. Quando um siste- 
ma de arquivos não é mais necessário, ele pode ser desmontado com a chamada de sistema 
umount. 
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O MINIX 3 mantém uma cache de blocos recentemente usados na memória principal 
para evitar a necessidade de lê-los do disco, se eles forem utilizados outra vez em um curto 
espaço de tempo. Se um bloco que está na cache for modificado (por uma operação write em 
um arquivo) e o sistema falhar antes do bloco modificado ser escrito no disco, o sistema de 
arquivos será danificado. Para limitar o possível dano, é importante esvaziar a cache perio- 
dicamente, para que o volume de dados perdidos por causa de uma falha seja pequeno. A 
chamada de sistema sync diz ao MINIX 3 para escrever no disco todos os blocos da cache 
que foram modificados desde que foram lidos. Quando o MINIX 3 é iniciado, um programa 
chamado update é lançado como um processo de segundo plano para executar uma chamada 
sync a cada 30 segundos, com o objetivo de esvaziar a cache (flushing). 

Duas outras chamadas relacionadas com diretórios são chdir e chroot. A primeira muda 
o diretório de trabalho e a última muda o diretório-raiz. Depois da chamada 


chdir (“/usr/ast/test”); 


uma chamada open no arquivo xyz abrirá /usr/ast/test/xyz. chroot funciona de maneira aná- 
loga. Quando um processo tiver dito ao sistema para que mude seu diretório raiz, todos os 
nomes de caminho absolutos (nomes de caminho começando com “/”) começarão em uma 
nova raiz. Por que você desejaria fazer isso? Por segurança — os programas servidores que 
implementam protocolos, como FTP (File Transfer Protocol) e HTTP (HyperText Tranfer 
Protocol), fazem isso para que os usuários remotos desses serviços possam acessar apenas as 
partes de um sistema de arquivos que estão abaixo da nova raiz. Apenas superusuários podem 
executar chroot, e mesmo eles não fazem isso com muita fregiiência. 


Chamadas de sistema para proteção 


No MINIX 3 cada arquivo tem um modo de proteção dado em 11 bits. Nove deles são os bits 
de leitura-escrita-execução para o proprietário, para o grupo e para outros. A chamada de 
sistema chmod torna possível mudar o modo de proteção de um arquivo. Por exemplo, para 
tornar um arquivo somente para leitura para todos, exceto o proprietário, pode-se executar 


chmod (“file”, 0644); 


Os outros dois bits de proteção, 02000 e 04000, são os bits de SETGID (set-group-id) 
e SETUID (set-user-id), respectivamente. Quando um usuário executa um programa com o 
bit SETUID ativado, o UID efetivo do usuário é alterado para o do proprietário do arquivo 
até o término desse processo. Esse recurso é intensamente utilizado para permitir que os 
usuários executem programas que efetuam funções exclusivas do superusuário, como a cria- 
ção de diretórios. A criação de um diretório utiliza mknod, que é exclusiva do superusuário. 
Tomando-se providências para que o programa mkdir pertença ao superusuário e tenha o 
modo 04755, os usuários normais podem ter o poder de executar mknod, mas de um modo 
bastante restrito. 

Quando um processo executa um arquivo que tem o bit SETUID, ou SETGID, ativado 
em seu modo de proteção, ele adquire um UID ou GID efetivo diferente de seu UID ou GID 
real. Às vezes, é importante que um processo saiba qual é o seu UID ou GID efetivo e real. As 
chamadas de sistema getuid e getgid foram providenciadas para fornecer essas informações. 
Cada chamada retorna o UID ou GID efetivo e real, de modo que quatro rotinas de biblioteca 
são necessárias para extrair as informações corretas: getuid, getgid, geteuid e getegid. As duas 
primeiras obtêm o UID/GID real e as últimas duas, os efetivos. 

Usuários normais não podem alterar seu UID, exceto executando programas com o bit 
SETUID ativado, mas o superusuário tem outra possibilidade: a chamada de sistema setuid, 
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que configura os UIDs real e efetivo. setgid configura os dois GIDs, real e efetivo. O superu- 
suário também pode alterar o proprietário de um arquivo com a chamada de sistema chown. 
Em suma, o superusuário tem várias oportunidades para violar todas as regras de proteção, 
o que explica por que tantos estudantes dedicam tanto de seu tempo tentando tornarem-se 
superusuários. 

As últimas duas chamadas de sistema nesta categoria podem ser executadas por proces- 
sos de usuários normais. A primeira, umask, configura uma máscara de bits interna dentro 
do sistema, que é utilizada para mascarar bits de modo quando um arquivo é criado. Após a 
chamada 


umask(022); 


o modo fornecido por creat e mknod terá os bits 022 mascarados antes de serem utilizados. 
Assim a chamada 


creat (“file”, 0777); 


configurará o modo como 0755, em vez de 0777. Como a máscara de bits é herdada pelos 
processos filhos, se o shell executar uma instrução umask imediatamente após o login, ne- 
nhum dos processos do usuário nessa sessão criará acidentalmente arquivos em que outras 
pessoas possam escrever. 

Quando um programa pertencente pelo usuário root tem o bit SETUID ativado, ele 
pode acessar qualquer arquivo, pois seu UID efetivo é o superusuário. Frequentemente, é 
útil o programa saber se a pessoa que o ativou tem permissão para acessar determinado 
arquivo. Se o programa simplesmente tentar o acesso, ele sempre terá êxito e, portanto, não 
saberá nada. 

O que é necessário é uma maneira de ver se o acesso é permitido para o UID real. A 
chamada de sistema access fornece uma forma de descobrir isso. O parâmetro mode é 4 para 
verificar acesso de leitura, 2 para acesso de escrita e 1 para acesso de execução. Combinações 
desses valores também são permitidas. Por exemplo, com mode igual a 6, a chamada retorna 
O se são permitidos acesso de leitura e escrita para o UID real; caso contrário, será retornado 
-1. Com mode igual a 0, é feita uma verificação para ver se o arquivo existe e se os diretórios 
que levam a ele podem ser pesquisados. 

Embora os mecanismos de proteção de todos os sistemas operacionais do tipo UNIX 
geralmente sejam semelhantes, existem algumas diferenças e inconsistências que levam a 
vulnerabilidades de segurança. Consulte Chen et al. (2002) para ver uma discussão sobre o 
assunto. 


Chamadas de sistema para gerenciamento de tempo 


O MINIX 3 tem quatro chamadas de sistema que envolvem o tempo de relógio convencio- 
nal. time retorna apenas a hora atual, em segundos, com 0 correspondendo à meia-noite de 
1º de janeiro de 1970 (exatamente quando o dia está iniciando, não quando está acabando). 
Naturalmente, o relógio do sistema deve ser ajustado em algum ponto para que possa ser 
lido posteriormente; portanto, stime foi fornecida para permitir que o relógio seja ajustado 
(pelo superusuário). A terceira chamada de tempo é utime, que permite ao proprietário de um 
arquivo (ou o superusuário) alterar o tempo armazenado no i-node de um arquivo. A aplica- 
ção desta chamada de sistema é bastante limitada, mas alguns programas precisam dela; por 
exemplo, touch, que altera o horário de um arquivo para a data e hora atuais. 

Finalmente, temos times, que retorna as informações de contabilização de um proces- 
so, para que se possa ver quanto tempo de CPU foi utilizado diretamente e quanto tempo 
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de CPU o sistema em si gastou em seu nome (manipulando suas chamadas de sistema). 
Também são fornecidos os tempos de usuário e de sistema totais utilizados por todos os seus 
filhos combinados. 


ARQUITETURA DE SISTEMAS OPERACIONAIS 


Agora que vimos como os sistemas operacionais se parecem externamente (isto é, a interfa- 
ce do programador), é hora de vê-los por dentro. Nas seções a seguir, examinaremos cinco 
arquiteturas diferentes que foram experimentadas, para termos uma idéia do espectro de pos- 
sibilidades. De modo algum elas são exaustivas, mas dão uma idéia de alguns projetos que 
foram experimentados na prática. Os cinco projetos são os sistemas monolíticos, os sistemas 
em camadas, as máquinas virtuais, os exonúcleos e os sistemas cliente-servidor. 


Sistemas monolíticos 


Com certeza, esta é a organização mais comum. Esta estratégia poderia muito bem ser deno- 
minada “A Grande Bagunça”. Essa estruturação é tal que não há nenhuma estrutura. O siste- 
ma operacional é escrito como um conjunto de rotinas, cada uma das quais podendo chamar 
qualquer uma das outras sempre que precisar. Quando essa técnica é utilizada, cada rotina do 
sistema tem uma interface bem-definida em termos de parâmetros e de resultados e cada uma 
está livre para chamar qualquer uma das outras, se a última fornecer alguma computação útil 
de que a primeira precise. 

Para construir o programa-objeto do sistema operacional, quando essa estratégia é uti- 
lizada, primeiro deve-se compilar todas as rotinas individualmente (ou os arquivos que con- 
tenham as rotinas) e, então, ligá-las em um único arquivo objeto usando o ligador (linker) do 
sistema. Em termos de ocultação de informações, não há basicamente nenhuma-toda rotina 
é visível para todas as demais (em oposição a uma estrutura contendo módulos ou pacotes, 
na qual muitas informações são ocultadas dentro dos módulos e apenas os pontos de entrada 
oficialmente designados podem ser chamados de fora do módulo). 

Contudo, mesmo nos sistemas monolíticos é possível ter pelo menos um pouco de es- 
truturação. Os serviços (chamadas de sistema) fornecidos pelo sistema operacional são soli- 
citados colocando-se os parâmetros em lugares bem definidos, como em registradores ou na 
pilha e, então, executando-se uma instrução de interrupção especial, conhecida como chama- 
da de núcleo ou chamada de supervisor. 

Essa instrução troca a máquina do modo usuário para modo núcleo e transfere o con- 
trole para o sistema operacional. (A maioria das CPUs tem dois modos: modo núcleo, para o 
sistema operacional, no qual todas as instruções são permitidas, e modo usuário, para progra- 
mas de usuário, no qual algumas instruções não são permitidas como as relacionadas a E/S, 
entre outras.) 

Este é um bom momento para vermos como as chamadas de sistema são executadas. 
Lembre-se de que a chamada read é usada como segue: 


count = read(fd, buffer, nbytes); 


Para executar a função de biblioteca read, que realmente faz a chamada de sistema read, 
o programa primeiro insere os parâmetros na pilha, como se vê nas etapas 1-3 da Figura 1- 
16. Os compiladores C e C++ colocam os parâmetros na pilha na ordem inversa por motivos 
históricos (relacionados ao fato de fazer com que o primeiro parâmetro de printf, a string de 
formato, apareça no topo da pilha). O primeiro e o terceiro parâmetros são chamados por va- 
lor, mas o segundo parâmetro é passado por referência, significando que é passado o endereço 
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Endereço 
OxFFFFFFFF 


Desvio para o núcleo (trap) read da 


5| Põe código da operação biblioteca 
read no registrador 


Retorna para o invocador (rotina) i Função 


Espaço de usuário < ERR T 


Empilha fd Programa do usuário 
Empilha &buffer executando read 


Empilha nbytes 


Rotina de 
chamada 


Espaço de núcleo < 
de sistema 


(sistema operacional) 


0 


Figura 1-16 As 11 etapas para fazer a chamada de sistema read(fd, buffer, nbytes). 


do buffer (indicado por &) e não o seu conteúdo. Em seguida, vem a chamada real para a 
função read da biblioteca (etapa 4) que é, essencialmente, uma chamada normal de execução 
de qualquer rotina. 

A função da biblioteca, possivelmente escrita em linguagem assembly, normalmente 
coloca o código numérico correspondente à chamada de sistema em um lugar esperado pelo 
sistema operacional, como em um registrador (etapa 5). Em seguida, ela executa uma ins- 
trução TRAP para trocar do modo usuário para o modo núcleo e iniciar a execução em um 
endereço fixo dentro do núcleo (etapa 6). O núcleo inicia examinando o código numérico da 
chamada de sistema para depois chamar a rotina de tratamento correta. Normalmente, isso é 
feito através de uma tabela de ponteiros para rotinas de tratamento de chamada de sistema, 
indexada pelo número de chamada de sistema (etapa 7). Nesse ponto, a rotina de tratamento 
de chamada de sistema é executada (etapa 8). Quando a rotina de tratamento de chamada de 
sistema terminar seu trabalho, o controle poderá ser retornado para a função de biblioteca no 
espaço de usuário, na instrução que segue a instrução TRAP (etapa 9). Essa função então re- 
torna para o programa do usuário, da maneira normal como as chamadas de função retornam 
(etapa 10). 

Para concluir a tarefa, o programa do usuário precisa limpar a pilha, como faz após 
qualquer chamada de rotina (etapa 11). Supondo que a pilha cresça para baixo, como aconte- 
ce freqüentemente, o código compilado incrementa o ponteiro da pilha exatamente o suficien- 
te para remover os parâmetros colocados antes da chamada de read. Agora o programa está 
livre para fazer o que quiser em seguida. 

Na etapa 9 anterior, dissemos que o controle “poderá ser retornado para a função de 
biblioteca no espaço de usuário”, por um bom motivo. A chamada de sistema pode bloquear o 
processo que fez a chamada, impedindo-o de continuar. Por exemplo, se ele estiver tentando 
ler o teclado e nada tiver sido digitado ainda, o processo que fez a chamada será bloqueado. 
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Nesse caso, o sistema operacional verificará se algum outro processo pode ser executado em 
seguida. Posteriormente, quando a entrada desejada estiver disponível, esse processo receberá 
a atenção do sistema e as etapas 9-1 1 ocorrerão. 
Essa organização sugere uma estrutura básica para o sistema operacional: 
1. Um programa principal que ativa a função de serviço solicitada. 
2. Um conjunto de funções de serviço que executam as chamadas de sistema. 
3. Um conjunto de funções utilitárias que ajudam as funções de serviço. 
Nesse modelo, para cada chamada de sistema há uma função de serviço que cuida dela. 
As funções utilitárias fazem coisas que são necessárias para várias funções de serviço, como 


buscar dados de programas de usuário. Essa divisão das funções em três camadas aparece na 
Figura 1-17. 


Função 
principal 


Funções 
de serviço 


Funções 
utilitárias 


Figura 1-17 Um modelo simples de estruturação para um sistema monolítico. 


Sistemas em camadas 


Uma generalização da estratégia da Figura 1-17 é organizar o sistema operacional como uma 
hierarquia de camadas, cada uma construída sobre a outra. O primeiro sistema feito dessa 
maneira foi o THE, construído no Technische Hogeschool Eindhoven, na Holanda, por E. 
W. Dijkstra (1968) e seus alunos. O sistema THE era um sistema em lote simples para um 
computador holandês, o Electrologica X8, que tinha 32K de palavras de 27 bits (os bits eram 
caros naquela época). 

O sistema tinha seis camadas, como mostrado na Figura 1-18. A camada O tratava da 
alocação do processador, alternando entre processos quando ocorriam interrupções ou quan- 
do temporizadores expiravam. Acima da camada 0, o sistema possuía processos segiienciais, 
cada um dos quais podia ser programado sem se preocupar com o fato de que vários pro- 
cessos estavam sendo executados num único processador. Em outras palavras, a camada O 
proporcionava a multiprogramação básica da CPU. 

A camada 1 fazia o gerenciamento de memória. Ela alocava espaço para processos na 
memória principal e em um tambor* com 512K de palavras, utilizado para conter partes dos 
processos (páginas) para os quais não havia espaço na memória principal. Acima da camada 
1, os processos não tinham que se preocupar com o fato de estarem na memória ou no tambor; 
o software da camada 1 tratava de assegurar que as páginas fossem levadas para a memória 
sempre que fossem necessárias. 


* N. de R. T.: Antigo meio magnético de armazenamento de dados. 
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Camada Função 
5 Operador 
4 Programas de usuário 
3 Gerenciamento de entrada/saída 
2 Comunicação operador-processo 
1 Gerenciamento de memória e tambor 
0 Alocação do processador e multiprogramação 


Figura 1-18 Estrutura do sistema operacional THE. 


A camada 2 manipulava a comunicação entre cada processo e o console do operador. 
Acima dessa camada, cada processo tinha efetivamente seu próprio console de operador. A 
camada 3 gerenciava os dispositivos de E/S e armazenava em buffer os fluxos de informação. 
Acima da camada 3, cada processo podia lidar com dispositivos de E/S abstratos com inter- 
faces amigáveis, em vez de dispositivos reais cheios de peculiaridades. A camada 4 era onde 
ficavam os programas de usuário. Eles não tinham de preocupar-se com gerenciamento de 
processos, de memória, de console ou de E/S. O processo do operador do sistema localizava- 
se na camada 5. 

Uma generalização maior do conceito de camadas estava presente no sistema MUL- 
TICS. Em vez de camadas, o MULTICS era organizado como uma série de anéis concêntri- 
cos, com os anéis internos sendo mais privilegiados do que os externos. Quando uma função 
em um anel externo queria chamar uma função em um anel interno, ela tinha de fazer o 
equivalente de uma chamada de sistema; isto é, uma instrução TRAP cuja validade dos parâ- 
metros era cuidadosamente verificada, antes de permitir que a chamada prosseguisse. Embora 
no MULTICS o sistema operacional inteiro fizesse parte do espaço de endereçamento de cada 
processo de usuário, o hardware tornava possível designar individualmente funções (na reali- 
dade, segmentos de memória) como protegidas contra leitura, escrita ou execução. 

Embora o esquema em camadas do THE fosse, na verdade, apenas um auxílio para 
projeto, porque todas as partes do sistema estavam, em última análise, ligadas a um único 
programa objeto, no MULTICS o mecanismo de anéis estava muito presente em tempo de 
execução e era imposto pelo hardware. A vantagem do mecanismo de anéis é que ele podia 
ser estendido facilmente para estruturar subsistemas de usuário. Por exemplo, um professor 
podia escrever um programa para testar e avaliar programas dos alunos e executar esse pro- 
grama no anel n, com os programas dos alunos sendo executado no anel n + 1, de modo que 
eles não podiam alterar suas avaliações. O hardware Pentium suporta a estrutura em anéis do 
MULTICS, mas atualmente nenhum sistema operacional importante a utiliza. 


Máquinas virtuais 


As versões iniciais do 0S/360 eram estritamente sistemas de lote. Não obstante, muitos usuá- 
rios do 360 queriam ter tempo compartilhado; assim, vários grupos, tanto de dentro como 
de fora da IBM, decidiram escrever sistemas de tempo compartilhado para ele. O sistema 
de tempo compartilhado oficial da IBM, o TSS/360, foi lançado tardiamente e quando fi- 
nalmente chegou era tão grande e lento que poucos ambientes foram convertidos para ele. 
Finalmente, ele acabou sendo abandonado depois que seu desenvolvimento tinha consumido 
algo em torno de US$ 50 milhões (Graham, 1970). Mas um grupo no Centro Científico da 
IBM em Cambridge, Massachusetts, produziu um sistema radicalmente diferente que a IBM 
acabou aceitando como produto e que agora é amplamente utilizado em seus computadores 
de grande porte. 
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Esse sistema, originalmente chamado CP/CMS e posteriormente rebatizado como 
VM/370 (Seawright e MacKinnon, 1979), foi baseado em uma observação muito perspicaz: 
um sistema de tempo compartilhado fornece (1) multiprogramação e (2) uma máquina esten- 
dida com uma interface mais conveniente que o hardware básico. A característica básica do 
VM/370 foi separar completamente essas duas funções. 

O centro do sistema, conhecido como monitor de máquina virtual, era executado no 
hardware básico e fazia a multiprogramação, oferecendo não uma, mas várias máquinas vir- 
tuais à camada superior seguinte, como mostrado na Figura 1-19. Entretanto, ao contrário de 
todos os outros sistemas operacionais, essas máquinas virtuais não eram máquinas estendi- 
das, com arquivos e com outros recursos interessantes. Em vez disso, elas eram cópias exatas 
do hardware básico, incluindo os modos núcleo e usuário, E/S, interrupções e tudo mais que 
uma máquina real tem. 


370s virtuais 


E O RR pf Chamadas de sistema 
aids aa 


Interrupção (trap) VM/370 


Interrupção (trap) 


Hardware básico do 370 


Figura 1-19 A estrutura do VM/370 com CMS. 


Como cada máquina virtual é idêntica ao hardware verdadeiro, cada uma pode executar 
qualquer sistema operacional que fosse executado diretamente no hardware básico. Dife- 
rentes máquinas virtuais podem executar (e fregientemente executam) diferentes sistemas 
operacionais. Algumas executam um dos descendentes do OS/360 para processamento de 
transações ou de lote, enquanto outras executam um sistema interativo monousuário chamado 
CMS (Conversational Monitor System) para usuários de tempo compartilhado. 

Quando um programa CMS executa uma chamada de sistema, a chamada é capturada 
pelo sistema operacional em sua própria máquina virtual e não pelo VM/370, exatamente 
como aconteceria se estivesse executando em uma máquina real. Então, o CMS envia as 
instruções normais de E/S de hardware para ler seu disco virtual ou o que for necessário 
para executar a chamada. Essas instruções de E/S são capturadas pelo VM/370, que então as 
executa como parte de sua simulação do hardware real. Fazendo uma separação completa das 
funções de multiprogramação e fornecendo uma máquina estendida, cada uma das partes se 
torna muito mais simples, mais flexível e mais fácil de manter. 

A idéia de máquina virtual é utilizada hoje em dia em um contexto diferente: na execu- 
ção de programas antigos do MS-DOS em um processador Pentium. Ao projetar o Pentium e o 
seu software, a Intel e a Microsoft perceberam que haveria uma grande demanda para executar 
software antigo (legado) no novo hardware. Por essa razão, a Intel fornece um modo virtual do 
8086 no Pentium. Nesse modo, a máquina age como um 8086 (que é idêntico a um 8088 do 
ponto de vista do software), incluindo o endereçamento de 16 bits com um limite de IMB. 

Este modo é utilizado pelo Windows e por outros sistemas operacionais para execu- 
tar programas antigos do MS-DOS. Esses programas são iniciados no modo 8086 virtual. 
Contanto que executem instruções normais, eles funcionam no hardware básico. Entretanto, 
quando um programa tenta interromper o sistema operacional para fazer uma chamada de 
sistema, ou tenta fazer E/S protegida diretamente, ocorre uma interrupção no monitor da 
máquina virtual. 
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Duas variantes desse projeto são possíveis. Na primeira, o próprio MS-DOS é carrega- 
do no espaço de endereçamento do 8086 virtual, de modo que o monitor da máquina virtual 
apenas reflete a interrupção para o MS-DOS, exatamente como aconteceria em um 8086 real. 
Quando, posteriormente, o próprio MS-DOS tentar fazer a E/S, essa operação será capturada 
e executada pelo monitor da máquina virtual. 

Na outra variante, o monitor da máquina virtual apenas captura a primeira interrupção 
e faz a E/S sozinho, pois conhece todas as chamadas de sistema do MS-DOS e, portanto, o 
que cada interrupção deve fazer. Esta variante é menos pura do que a primeira, já que simula 
corretamente apenas o MS-DOS e não outros sistemas operacionais, como acontece com a 
primeira. Por outro lado, ela é muito mais rápida, pois elimina o problema de iniciar o MS- 
DOS para fazer a E/S. Uma desvantagem de executar o MS-DOS no modo 8086 virtual é que 
o MS-DOS desperdiça muito tempo habilitando e desabilitando interrupções, o que implica 
em custo considerável (em tempo) para simular um processo. 

Vale notar que nenhuma dessas estratégias é realmente igual à do VM/370, pois a má- 
quina que está sendo simulada não é um Pentium completo, mas apenas um 8086. No sistema 
VM/370 é possível executar o próprio VM/370 na máquina virtual. Até as primeiras versões 
do Windows exigem pelo menos um 286 e não podem ser executadas em um 8086 virtual. 

Diversas implementações de máquina virtual são vendidas comercialmente. Para em- 
presas que fornecem serviços de hospedagem web, pode ser mais econômico executar várias 
máquinas virtuais em um único servidor rápido (talvez com várias CPUs) do que executar 
muitos computadores pequenos, cada um hospedando um único site web. O VMWare e o 
Virtual PC da Microsoft são comercializados para tais instalações. Esses programas utili- 
zam arquivos grandes no sistema hospedeiro (host) para simular os discos de seus sistemas 
convidados (guest); aqueles que são executados pela máquina virtual. Para obter eficiência, 
eles analisam os arquivos binários do programa de sistema convidado e permitem que código 
seguro seja executado diretamente no hardware do hospedeiro, capturando instruções que 
fazem chamadas de sistema operacional. Tais sistemas também são úteis para fins didáticos. 
Por exemplo, alunos que estejam trabalhando em tarefas de laboratório no MINIX 3 podem 
usar esse sistema operacional como convidado no VMWare em um hospedeiro Windows, 
Linux ou UNIX, sem correrem o risco de danificar outro software instalado no mesmo PC. 
A maioria dos professores que dão aulas sobre outros temas ficaria muito preocupada com o 
fato de compartilhar computadores do laboratório com um curso sobre sistemas operacionais, 
onde erros dos alunos poderiam corromper ou apagar dados do disco. 

Outra área onde as máquinas virtuais são usadas, mas de uma maneira um tanto dife- 
rente, é na execução de programas Java. Quando a Sun Microsystems inventou a linguagem 
de programação Java, inventou também uma máquina virtual (isto é, uma arquitetura de com- 
putador) chamada JVM (Java Virtual Machine — máquina virtual Java). O compilador Java 
produz código para a JVM, o qual então é normalmente executado por um interpretador JVM, 
em software. A vantagem dessa estratégia é que o código da JVM pode ser enviado pela Inter- 
net para qualquer computador que tenha um interpretador JVM e executado no destino. Se o 
compilador tivesse produzido programas binários em SPARC ou Pentium, por exemplo, eles 
não poderiam ser enviados e executados em qualquer lugar tão facilmente. (É claro que a Sun 
poderia ter produzido um compilador que gerasse binários em SPARC e depois distribuído 
um interpretador SPARC, mas a JVM é uma arquitetura muito mais simples de interpretar.) 
Outra vantagem de usar a JVM é que, se o interpretador for implementado corretamente, o 
que não é totalmente simples, a segurança dos programas JVM recebidos poderá ser verifi- 
cada e eles poderão ser executados em um ambiente protegido, para que não possam roubar 
dados ou causar qualquer dano. 
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1.5.4 


1.5.5 


Exonúcleos 


Com o VM/370, cada processo de usuário recebe uma cópia exata do hardware real. No modo 
8086 virtual do Pentium, cada processo de usuário recebe uma cópia exata de um computador 
diferente. Indo um pouco mais longe, os pesquisadores do M.LT. construíram um sistema 
que fornece um clone do computador real para cada usuário, mas com um subconjunto dos 
recursos (Engler et al., 1995 e Leschke, 2004). Assim, uma máquina virtual poderia receber 
os blocos de disco de O a 1023, a seguinte poderia receber os blocos de 1024 a 2047 e assim 
por diante. 

Na camada inferior, executando em modo núcleo, existe um programa chamado exo- 
núcleo (exokernel). Sua tarefa é alocar recursos para as máquinas virtuais e, então, verificar 
tentativas de utilizá-los para garantir que nenhuma máquina use recursos pertencentes à outra 
pessoa. Cada máquina virtual em nível de usuário pode executar seu próprio sistema opera- 
cional, como no VM/370 e nos 8086 virtuais do Pentium, exceto que cada uma está limitada 
a usar apenas os recursos que solicitou e que foram alocados. 

A vantagem do esquema de exonúcleo é que ele economiza uma camada de mapea- 
mento. Em outros projetos, cada máquina virtual “enxerga” um disco próprio, com blocos 
que vão de 0 até algum máximo, de modo que o monitor de máquina virtual precisa manter 
tabelas para fazer um novo mapeamento dos endereços de disco (e todos os outros recursos). 
Com o exonúcleo, esse novo mapeamento não é necessário. O exonúcleo só precisa monito- 
rar qual recurso foi designado para qual máquina virtual. Esse método tem ainda a vantagem 
de separar a multiprogramação (no exonúcleo) do código do sistema operacional do usuário 
(no espaço de usuário), mas com menor sobrecarga, pois o exonúcleo precisa apenas manter 
as máquinas virtuais separadas. 


Modelo cliente-servidor 


O VM/370 ganha muito em simplicidade, movendo grande parte do código do sistema opera- 
cional tradicional (implementando a máquina estendida) para uma camada mais alta, a CMS. 
Entretanto, o VM/370 em si ainda é um programa complexo, pois simular diversos 370 vir- 
tuais não é tão simples assim (especialmente se você quiser fazer isso de maneira razoavel- 
mente eficiente). 

Uma tendência nos sistemas operacionais modernos é levar ainda mais longe essa idéia 
de mover código para camadas mais altas e remover o máximo possível do sistema opera- 
cional, deixando um núcleo mínimo, o micronúcleo (microkernel). A estratégia normal é 
implementar a maior parte das funções do sistema operacional em processos de usuário. Para 
solicitar um serviço, como ler um bloco de um arquivo, um processo de usuário (agora conhe- 
cido como processo cliente) envia uma requisição para um processo servidor, o qual então 
realiza o trabalho e devolve a resposta. 

Nesse modelo, ilustrado na Figura 1-20, tudo que o núcleo faz é gerenciar a comunica- 
ção entre clientes e servidores. Dividir o sistema operacional em partes, cada uma gerencian- 
do apenas uma faceta do sistema, como serviços de arquivo, serviços de processo, serviços 
de terminal ou serviços de memória, torna cada parte pequena e gerenciável. Além disso, 
como todos os servidores são executados como processos em modo usuário e não em modo 
núcleo, eles não têm acesso direto ao hardware. Como conseqiiência, se ocorrer um erro no 
servidor de arquivos, o serviço de arquivos pode falhar, mas isso normalmente não derrubará 
a máquina inteira. 

Outra vantagem do modelo cliente-servidor é sua capacidade de adaptação para uso 
em sistemas distribuídos (veja a Figura 1-21). Se um cliente se comunica com um servidor 
enviando mensagens a ele, o cliente não precisa saber se a mensagem é manipulada de forma 
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Processo i i Sistema de|Servidor de 
cliente cliente | processos | terminal arquivos | memória 


Modo usuário 


- - Modo núcleo 
Micronúcleo 


O cliente obtém 

o serviço enviando 
mensagens para 
processos servidores 


Figura 1-20 O modelo cliente-servidor. 


local em sua própria máquina ou se foi enviada para um servidor em uma máquina remota 
por meio de uma rede. No que diz respeito ao cliente, a mesma coisa acontece nos dois casos: 
uma requisição foi enviada e uma resposta retornou. 


Máquina 1 Máquina 2 Máquina 3 Máquina 4 


Cliente 


Sistema de arquivos 


Í Núcleo 


Mensagem do cliente 
para o servidor 


Figura 1-21 O modelo cliente-servidor em um sistema distribuído. 


A figura esboçada acima, de um núcleo que manipula apenas o envio de mensagens de 
clientes para servidores e vice-versa, não é completamente realista. Algumas funções do sis- 
tema operacional (como a carga de comandos nos registradores de dispositivos de E/S físicos) 
são difíceis, senão impossíveis, de serem feitos a partir de programas em espaço de usuário. 
Há duas maneiras de lidar com esse problema. Uma delas é fazer com que alguns processos 
servidores críticos (por exemplo, os drivers de dispositivo de E/S) sejam executados real- 
mente em modo núcleo, com acesso completo a todo o hardware, mas ainda se comuniquem 
com outros processos, utilizando o mecanismo normal de mensagens. 

A outra maneira é construir um mínimo do mecanismo no núcleo, deixando as decisões 
políticas para os servidores no espaço de usuário. Por exemplo, o núcleo poderia reconhecer 
que uma mensagem enviada para um certo endereço especial significa pegar o conteúdo dessa 
mensagem e carregá-lo nos registradores do dispositivo de E/S de algum disco, para iniciar 
uma leitura de disco. Nesse exemplo, o núcleo nem mesmo inspecionaria os bytes presentes 
na mensagem para ver se seriam válidos ou significativos; ele apenas os copiaria cegamente 
nos registradores de dispositivo do disco. (Obviamente, deve ser utilizado algum esquema 
para restringir essas mensagens apenas aos processos autorizados.) A divisão entre mecanis- 
mo e política é um conceito importante; ela ocorre repetidamente nos sistemas operacionais 
em diversos contextos. 


VISÃO GERAL DO RESTANTE DESTE LIVRO 


Normalmente, os sistemas operacionais têm quatro componentes principais: gerenciamento 
de processos, gerenciamento de dispositivos de E/S, gerenciamento de memória e gerencia- 
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mento de arquivos. O MINIX 3 também é dividido nessas quatro partes. Os próximos quatro 
capítulos tratam desses quatro temas, um por capítulo. O Capítulo 6 contêm uma lista de 
leituras sugeridas e uma bibliografia. 

Os capítulos sobre processos, E/S, gerenciamento de memória e sistema de arquivos têm 
a mesma estrutura geral. Primeiro são expostos os princípios gerais do assunto. Em seguida, 
é apresentada uma visão geral da área correspondente do MINIX 3 (que também se aplica 
ao UNIX). Finalmente, a implementação do MINIX 3 é discutida em detalhes. A seção de 
implementação pode ser estudada superficialmente, ou até pulada, sem perda de continuidade 
para os leitores que estejam interessados apenas nos princípios dos sistemas operacionais e 
não no código do MINIX 3. Os leitores que estiverem interessados em saber como funciona 
um sistema operacional real (o MINIX 3) devem ler todas as seções. 


RESUMO 


Os sistemas operacionais podem ser considerados sob dois pontos de vista: gerenciadores 
de recursos e máquinas estendidas. Na visão de gerenciador de recursos, a tarefa do sistema 
operacional é gerenciar eficientemente as diferentes partes do sistema. Na visão de máquina 
estendida, a tarefa do sistema é oferecer aos usuários uma máquina virtual mais conveniente 
para usar do que a máquina real. 

Os sistemas operacionais têm uma longa história, iniciando na época em que substituí- 
ram o operador até os modernos sistemas de multiprogramação. 

O centro de qualquer sistema operacional é o conjunto de chamadas de sistema que ele 
pode manipular. Elas indicam o que o sistema operacional realmente faz. Para o MINIX 3, 
essas chamadas podem ser divididas em seis grupos. O primeiro grupo de chamadas de siste- 
ma está relacionado à criação e ao término de processos. O segundo grupo manipula sinais. O 
terceiro grupo serve para ler e escrever arquivos. Um quarto grupo serve para gerenciamento 
de diretório. O quinto grupo trata de proteção e o sexto grupo de aspectos relacionados ao 
tempo. 

Os sistemas operacionais podem ser estruturados de várias maneiras. As mais comuns 
são como um sistema monolítico, como uma hierarquia de camadas, como um sistema de 
máquina virtual, baseado em exonúcleo e usando o modelo cliente-servidor. 


PROBLEMAS 


1. Quais são as duas principais funções de um sistema operacional? 


2. Qual é a diferença entre modo núcleo e modo usuário? Por que a diferença é importante para um 
sistema operacional? 


3. O que é multiprogramação? 


4. O que é spooling? Você acredita que os computadores pessoais avançados terão spooling como um 
recurso padrão no futuro? 


5. Nos primeiros computadores, cada byte de dados lido ou escrito era diretamente tratado pela CPU 
(isto é, não havia DMA — Direct Memory Access — acesso direto à memória). Quais são as implica- 
ções dessa organização para a multiprogramação”? 


6. Por que o tempo compartilhado não era comum em computadores de segunda geração? 
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10. 


11. 


12. 


13. 


14. 


15. 


16. 


17. 


18. 


19. 


20. 


21. 


22. 


Quais das seguintes instruções devem ser permitidas apenas no modo núcleo? 


(a) Desabilitar todas interrupções. 

(b) Ler o relógio de hora do dia. 

(c) Configurar o relógio de hora do dia. 
(d) Mudar o mapeamento da memória. 


Relacione algumas diferenças entre os sistemas operacionais de computadores pessoais e os siste- 
mas operacionais de computadores de grande porte. 


Dê um motivo pelo qual um sistema operacional patenteado, de código-fonte fechado, como o 
Windows, deve ter qualidade melhor do que um sistema operacional de código-fonte aberto, como 
o Linux. Agora, dê um motivo pelo qual um sistema operacional de código-fonte aberto, como 
o Linux, deve ter qualidade melhor do que um sistema operacional patenteado, de código-fonte 
fechado, como o Windows. 


Um arquivo do MINIX, cujo proprietário tem UID = 12 e GID = 1, tem o modo rwxr-x---. Outro 
usuário, com UID = 6, GID = 1, tenta executar o arquivo. O que acontecerá? 


Em vista do fato de que a simples existência de um superusuário pode levar a todos os tipos de 
problemas de segurança, por que existe tal conceito? 


Todas as versões do UNIX suportam atribuição de nomes de arquivo usando caminhos absolutos 
(relativos à raiz) e caminhos relativos (relativos ao diretório de trabalho). E possível descartar um 
deles e usar apenas o outro? Se for assim, qual deles você sugeriria manter? 


Por que a tabela de processos é necessária em um sistema de tempo compartilhado? Ela também 
seria necessária em sistemas operacionais de computador pessoal, nos quais existe apenas um pro- 
cesso, com esse processo tomando conta da máquina inteira até que termine? 


Qual é a diferença básica entre um arquivo especial de bloco e um arquivo especial de caractere? 


No MINIX 3, se o usuário 2 cria um vínculo (link) para um arquivo pertencente ao usuário 1 e, 
então, o usuário 1 remove esse arquivo, o que acontece quando o usuário 2 tenta ler o arquivo? 


Os pipes são um recurso fundamental? Alguma funcionalidade importante seria perdida se eles não 
estivessem disponíveis? 


Os instrumentos modernos para o consumidor, como equipamentos estéreos e câmaras digitais, 
frequentemente têm uma tela na qual podem ser inseridos comandos e os resultados podem ser 
vistos. Muitas vezes, esses equipamentos têm interiormente um sistema operacional primitivo. A 
que parte de um software de computador pessoal o processamento de comandos por meio da tela 
de um equipamento estéreo ou de uma câmara é semelhante? 


O Windows não tem uma chamada de sistema fork, embora seja capaz de criar novos processos. Dê 
um palpite abalizado sobre a semântica da chamada de sistema utilizada pelo Windows para criar 
novos processos. 


Por que a chamada de sistema chroot é limitada ao superusuário? (Dica: pense nos problemas de 
proteção.) 


Examine a lista de chamadas de sistema da Figura 1-9. Qual delas você acha que provavelmente 
será executada mais rapidamente? Explique sua resposta. 


Suponha que um computador possa executar 1 bilhão de instruções/s e que uma chamada de siste- 
ma ocupe 1000 instruções, incluindo a interrupção e toda a troca de contexto. Quantas chamadas 
de sistema o computador pode executar por segundo e ainda ter metade da capacidade da CPU para 
executar código de aplicativos? 


Existe uma chamada de sistema mknod na Figura 1-16, mas não há chamada de rmnod. Isso signi- 
fica que você precisa tomar muito cuidado ao criar i-nodes dessa maneira porque não há meios de 
remover todos eles? 
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23. 


24. 
25. 


26. 


27. 


28. 


Por que o MINIX 3 tem o programa update executando em segundo plano (background) o tempo 
todo? 


Faz algum sentido ignorar o sinal SIGALRM? 


O modelo cliente-servidor é popular em sistemas distribuídos. Ele também pode ser utilizado em 
um sistema de um único computador? 


As versões iniciais do Pentium não suportavam um monitor de máquina virtual. Qual característica 
fundamental é necessária para permitir que uma máquina possa se tornar virtual? 


Escreva um programa (ou uma série de programas) para testar todas as chamadas de sistema do 
MINIX 3. Para cada chamada, experimente vários conjuntos de parâmetros, incluindo alguns in- 
corretos, para ver se eles são detectados. 


Escreva um shell semelhante ao da Figura 1-10, mas contendo código suficiente para realmente 
funcionar, de modo que você possa testá-lo. Você também poderia adicionar alguns recursos, como 
redirecionamento de entrada e saída, pipes e jobs em segundo plano (background). 


2.1 


2.1.1 


PROCESSOS 


Agora, estamos prestes a entrar em um estudo detalhado sobre como os sistemas operacionais 
em geral (e o MINIX 3 em particular) são projetados e construídos. O conceito central em 
qualquer sistema operacional é o de processo: uma abstração de um programa em execução. 
Tudo mais depende desse conceito e é importante que o projetista de sistema operacional (e 
o estudante) o entenda bem. 


INTRODUÇÃO 


Todos os computadores modernos podem fazer várias coisas ao mesmo tempo. Enquanto exe- 
cuta um programa do usuário, um computador também pode estar lendo um disco e gerando 
saída de texto em uma tela ou impressora. Em um sistema com multiprogramação, a CPU 
também alterna de um programa para outro, executando cada um deles por dezenas ou cen- 
tenas de milissegundos. Rigorosamente falando, a qualquer momento, enquanto a CPU está 
executando apenas um programa, durante 1 segundo ela pode trabalhar em vários programas, 
dando aos usuários a ilusão de paralelismo. Às vezes, as pessoas falam de pseudoparalelis- 
mo nesse contexto, para contrastar com o verdadeiro paralelismo de hardware dos sistemas 
multiprocessadores (que têm duas ou mais CPUs compartilhando a mesma memória física). 
É difícil para as pessoas acompanhar múltiplas atividades paralelas. Assim, com o passar 
dos anos, os projetistas de sistemas operacionais desenvolveram um modelo conceitual (os 
processos seqüenciais) que torna mais fácil tratar com o paralelismo. Esse modelo, suas apli- 
cações e algumas de suas conseqüências são o assunto deste capítulo. 


O modelo de processo 


Neste modelo, todo o software executável no computador, às vezes incluindo o sistema opera- 
cional, é organizado em diversos processos seqüenciais ou, para simplificar, apenas proces- 
sos. Um processo é simplesmente um programa em execução, incluindo os valores correntes 
do contador de programa, dos registradores e das variáveis. Conceitualmente, cada processo 
tem sua própria CPU virtual. É claro que, na verdade, a CPU alterna de um processo para 
outro, mas para entender o sistema é muito mais fácil pensar em um conjunto de processos 
executados em (pseudo) paralelo do que tentar acompanhar o modo como a CPU troca de um 
programa para outro. Essa rápida alternância é chamada de multiprogramação, como vimos 
no Capítulo 1. 
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Na Figura 2-1(a), vemos um computador multiprogramado com quatro programas em 
memória. Na Figura 2-1(b), vemos quatro processos, cada um com seu próprio fluxo de con- 
trole (isto é, seu próprio contador de programa) e cada um executando independentemente 
dos outros. É claro que existe apenas um contador de programa físico, de modo que, quando 
cada processo é executado, seu contador de programa lógico é carregado no contador de 
programa físico. Quando ele termina, o contador de programa físico é salvo no contador de 
programa lógico do processo, em memória. Na Figura 2-1(c), vemos que, observados por um 
intervalo de tempo suficientemente longo, todos os processos fizeram progresso, mas em um 
dado instante apenas um está sendo executado. 


Um contador de programa 


Quatro contadores de programa 
Alternância 


de processos 


Processo 
>v OU 
| 
| 


Tempo —— 


(a) (b) (c) 


Figura 2-1 (a) Multiprogramação de quatro programas. (b) Modelo conceitual de quatro 
processos seqüenciais independentes. (c) Apenas um programa está ativo em dado instante. 


Com a CPU alternando entre os processos, a velocidade com que um processo faz sua 
computação não será uniforme e, provavelmente, nem mesmo poderá ser reproduzida se os 
mesmos processos forem executados novamente. Assim, os processos não devem ser pro- 
gramados com suposições sobre temporização estabelecidas. Considere, por exemplo, um 
processo de E/S que inicializa uma fita streamer para restaurar o backup de arquivos, executa 
um laço de espera 10.000 vezes para permitir que ela atinja a velocidade correta e, depois, 
executa um comando para ler o primeiro registro. Se a CPU decidir trocar para outro processo 
durante o laço de espera, o processo da fita poderá não ser executado novamente até que o pri- 
meiro registro tenha passado pelo cabeçote de leitura. Quando um processo tem requisitos de 
tempo real críticos como esse (isto é, eventos particulares devem ocorrer dentro de um tempo 
específico), medidas especiais devem ser tomadas para garantir que eles sejam cumpridos. 
Normalmente, entretanto, a maioria dos processos não é afetada pela multiprogramação da 
CPU, nem pelas velocidades relativas dos diferentes processos. 

A diferença entre um processo e um programa é sutil, mas decisiva. Uma analogia pode 
ajudar a esclarecer esse ponto. Considere um profissional de computação com dotes culiná- 
rios que está assando um bolo de aniversário para sua filha. Ele tem uma receita de bolo e 
uma cozinha bem-equipada, com os ingredientes necessários: farinha, ovos, açúcar, essência 
de baunilha etc. Nessa analogia, a receita é o programa (isto é, um algoritmo expresso em 
alguma notação conveniente), o profissional de computação é o processador (CPU) e os in- 
gredientes do bolo são os dados de entrada. O processo é a atividade que consiste em nosso 
confeiteiro ler a receita, buscar os ingredientes e assar o bolo. 

Agora, imagine que o filho do profissional de computação apareça chorando, dizendo 
que foi picado por uma abelha. O profissional de computação memoriza o ponto onde estava 
na receita (o estado do processo atual é salvo), procura um manual de primeiros socorros e 
começa a seguir as orientações. Vemos aqui o processador alternando de um processo (assar) 
para outro de prioridade mais alta (prestar cuidados médicos), cada um tendo um programa 
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diferente (receita versus manual de primeiros socorros). Quando a picada de abelha tiver 
sido tratada, o profissional de computação volta para seu bolo, continuando a partir do ponto 
onde estava. 

A idéia-chave aqui é que um processo é um tipo de atividade. Ele tem um programa, 
entrada, saída e um estado. Um único processador pode ser compartilhado entre vários pro- 
cessos, com algum algoritmo de escalonamento sendo utilizado para determinar quando deve 
interromper o trabalho em um processo e atender outro. 


Criação de processos 


Os sistemas operacionais precisam de alguma maneira de garantir que todos os processos 
necessários existam. Em sistemas muito simples, ou em sistemas projetados para executar um 
único aplicativo (por exemplo, controlar um dispositivo em tempo real), é possível ter todos 
os processos que serão necessários presentes quando o sistema inicia. Contudo, nos sistemas 
de propósito geral, é necessário alguma maneira de criar e terminar processos durante a ope- 
ração. Veremos agora alguns dos problemas. 

Existem quatro eventos principais que acarretam a criação de processos: 


Inicialização do sistema. 


2. Realização de uma chamada de sistema por um processo em execução para criação 
de processo. 


3. Um pedido de usuário para criar um novo processo. 


4. Início de uma tarefa em lote. 


Quando um sistema operacional é inicializado, freqüentemente vários processos são 
criados. Alguns deles são processos de primeiro plano (foreground); isto é, processos que 
interagem com os usuários (humanos) e executam trabalho para eles. Outros são processos de 
segundo plano (background), os quais não são associados a usuários em particular, mas, em 
vez disso, têm alguma função específica. Por exemplo, um processo de segundo plano pode 
ser projetado para aceitar pedidos de páginas web contidas nessa máquina, sendo acionado 
quando chega um pedido para ser atendido. Os processos que ficam em segundo plano para 
executar alguma atividade, como buscar páginas web, impressão etc., são chamados de da- 
emons. Os sistemas grandes normalmente têm dezenas deles. No MINIX 3, o programa ps 
pode ser usado para listar os processos que estão em execução. 

Além dos processos criados no momento da inicialização, novos processos também po- 
dem ser criados depois. Freqüentemente, um processo em execução fará chamadas de sistema 
para criar um ou mais processos novos, para ajudá-lo a fazer seu trabalho. A criação de novos 
processos é particularmente útil quando o trabalho a ser feito pode ser facilmente formulado 
em termos de vários processos relacionados que estão interagindo, mas que são independen- 
tes. Por exemplo, ao se compilar um programa grande, o programa make ativa o compilador C 
para converter arquivos fonte em código objeto e depois ativa o programa install para copiar o 
programa em seu destino, configurar o proprietário e as permissões etc. No MINIX 3, o com- 
pilador C em si é, na realidade, composto por vários programas diferentes, os quais trabalham 
em conjunto. Isso inclui um pré-processador, um analisador sintático da linguagem C, um 
gerador de código em linguagem assembly, um montador e um ligador (linker). 

Nos sistemas interativos, os usuários podem iniciar um programa digitando um coman- 
do. No MINIX 3, consoles virtuais permitem que um usuário inicie um programa, digamos, 
um compilador, e depois troque para um console alternativo e inicie outro programa, talvez 
para editar a documentação, enquanto o compilador está em execução. 
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A última situação em que processos são criados se aplica apenas aos sistemas de lote 
encontrados nos computadores de grande porte. Aqui, os usuários podem submeter tarefas de 
lote para o sistema (possivelmente de forma remota). Quando o sistema operacional decide 
que tem recursos suficientes para executar outra tarefa, ele cria um novo processo e executa a 
próxima tarefa de sua fila de entrada. 

Tecnicamente, em todos esses casos, um novo processo é criado fazendo-se com que 
um processo existente execute uma chamada de sistema para criação de processo. Esse pro- 
cesso pode ser um processo de usuário em execução, um processo de sistema ativado a partir 
do teclado ou mouse, ou ainda um processo do gerenciador de lotes. O que esse processo faz 
é executar uma chamada de sistema para criar o novo processo. Essa chamada de sistema 
instrui o sistema operacional a criar um novo processo e indica, direta ou indiretamente, qual 
programa deve ser executado. 

No MINIX 3, existe apenas uma chamada de sistema para criar um novo processo: fork. 
Essa chamada cria um clone exato do processo que fez a chamada. Após a chamada de fork, 
os dois processos, o pai e o filho, têm a mesma imagem da memória, as mesmas strings de 
ambiente e os mesmos arquivos abertos. Isso é tudo. Normalmente, o processo filho executa 
então execve ou uma chamada de sistema similar, para alterar sua imagem da memória e 
executar um outro programa. Por exemplo, quando um usuário digita um comando, digamos, 
sort, no shell, este cria um processo filho e o filho executa sort. O motivo desse processo de 
duas etapas é permitir que o filho manipule seus descritores de arquivo após a chamada de 
fork, mas antes de execve, para fazer o redirecionamento da entrada padrão, da saída padrão 
e do erro padrão. 

No MINIX 3 e no UNIX, depois que um processo é criado, tanto o pai quanto o filho 
têm seus próprios espaços de endereçamento distintos. Se um dos processos alterar uma pala- 
vra em seu espaço de endereçamento, ela não será visível para o outro processo. O espaço de 
endereçamento inicial do filho é uma cópia do espaço de endereçamento do pai, mas existem 
dois espaços de endereçamento distintos envolvidos; nenhuma porção de memória passível 
de ser escrita é compartilhada (assim como em algumas implementações de UNIX, o MINIX 
3 pode compartilhar o texto do programa entre os dois, desde que não possa ser modificado). 
Entretanto, é possível que um processo recentemente criado compartilhe alguns outros recur- 
sos de seu criador, como os arquivos abertos. 


Término de processos 


Após um processo ser criado, ele começa a ser executado e faz seu trabalho, seja qual for. En- 
tretanto, nada dura para sempre, nem mesmo os processos. Mais cedo ou mais tarde, o novo 
processo terminará, normalmente devido a uma das seguintes condições: 


1. Término normal (voluntário) 

2. Término por erro (voluntário) 

3. Erro fatal (involuntário) 

4. Eliminado por outro processo (involuntário) 

A maioria dos processos termina porque já fez seu trabalho. Quando um compilador 
tiver compilado o programa recebido, ele executa uma chamada de sistema para dizer ao sis- 
tema operacional que terminou. No MINIX 3, essa chamada é a exit. Os programas também 
aceitam término voluntário. Por exemplo, os editores sempre têm uma combinação de teclas 


que o usuário pode utilizar para instruir o processo a salvar o arquivo de trabalho, remover os 
arquivos temporários que estão abertos e terminar. 
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O segundo motivo de término é o fato de o processo descobrir um erro fatal. Por exem- 
plo, se um usuário digitar o comando 


cc foo.c 


para compilar o programa foo.c e esse arquivo não existir, o compilador simplesmente en- 
cerrará. 

O terceiro motivo para o término é um erro causado pelo processo, talvez devido a um 
erro no programa. Exemplos incluem a execução de uma instrução inválida, referência à 
memória inexistente ou divisão por zero. No MINIX 3, um processo pode dizer ao sistema 
operacional que deseja tratar de certos erros sozinho, no caso em que o processo é sinalizado 
(interrompido), em vez de terminar quando um dos erros ocorre. 

O quarto motivo pelo qual um processo poderia terminar é o fato de executar uma 
chamada de sistema instruindo o sistema operacional a eliminar algum outro processo. No 
MINIX 3, essa chamada é a kill. É claro que o processo que vai eliminar o outro deve ter a au- 
torização necessária para isso. Em alguns sistemas, quando um processo termina, voluntaria- 
mente ou não, todos os processos que criou também são eliminados imediatamente. Contudo, 
o MINIX 3 não funciona assim. 


Hierarquia de processos 


Em alguns sistemas, quando um processo cria outro, o pai e o filho continuam associados 
de certas maneiras. O próprio filho pode criar mais processos, formando uma hierarquia de 
processos. Ao contrário das plantas e dos animais, que usam reprodução sexual, um processo 
tem apenas um pai (mas zero, um, dois ou mais filhos). 

No MINIX 3, um processo, seus filhos e outros descendentes podem, juntos, formar um 
grupo de processos. Quando um usuário envia um sinal do teclado, o sinal pode ser enviado 
para todos os membros do grupo de processos correntemente associados ao teclado (nor- 
malmente, todos os processos que foram criados na janela corrente). Isso é a dependência 
de sinal. Se um sinal é enviado para um grupo, cada processo pode capturá-lo, ignorá-lo ou 
executar a ação padrão, que é ser eliminado pelo sinal. 

Como um exemplo simples de como as árvores de processos são utilizadas, vamos ver 
como o MINIX 3 se inicializa. Dois processos especiais, o servidor de reencarnação e init 
estão presentes na imagem de boot. A tarefa do servidor de reencarnação é (re)iniciar drivers 
e servidores. Ele começa bloqueado, a espera de mensagens que o instrua sobre o que criar. 

Em contraste, init executa o script /etc/rc, que o faz enviar comandos para o servidor de 
reencarnação para iniciar os drivers e servidores ausentes na imagem de boot. Esse procedi- 
mento torna os drivers e os servidores filhos do servidor de reencarnação, de modo que, se 
qualquer um deles terminar, o servidor de reencarnação será informado e poderá reiniciá-los 
(isto é, reencarná-los) novamente. Esse mecanismo se destina a permitir que o MINIX 3 tole- 
re uma falha de driver ou de servidor, pois um novo driver ou servidor será iniciado automa- 
ticamente. Contudo, na prática, substituir um driver é muito mais fácil do que substituir um 
servidor, pois há menos repercussão em outras partes do sistema. (E não podemos dizer que 
isso sempre funciona perfeitamente; ainda há trabalho em andamento.) 

Quando init tiver terminado de fazer isso, ele lê um arquivo de configuração (/etc/ttytab) 
para ver quais terminais reais e virtuais existem. Init cria (com fork) um processo getty para 
cada um deles, exibe um prompt de login e depois espera pela entrada. Quando um nome é 
digitado, getty executa (com exec) um processo login tendo o nome como seu argumento. 
Se o usuário tiver êxito na conexão, login executará (com exec) o shell do usuário. Portanto, 
o shell é um filho de init. Comandos do usuário criam filhos do shell, os quais são netos de 
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init. Essa segiiência de eventos é um exemplo de como as árvores de processos são usadas. 
Contudo, os códigos do servidor de reencarnação e de init não estão listados neste livro; o 
shell também não está. A linha tinha de ser traçada em algum lugar. Mas agora você tem a 
idéia básica. 


Estados de um processo 


Embora cada processo seja uma entidade independente, com seu próprio contador de pro- 
grama, registradores, pilha, arquivos abertos, alarmes e outros estados internos, os processos 
freqientemente precisam interagir, se comunicar e se sincronizar com outros processos. Por 
exemplo, um processo pode gerar uma saída que outro processo utiliza como entrada. Nesse 
caso, os dados precisam ser movidos entre os processos. No comando de shell 


cat chapter1 chapter2 chapter3 | grep tree 


o primeiro processo, executando cat, concatena três arquivos e produz uma saída. O segundo 
processo, executando grep, seleciona todas as linhas que contêm a palavra “tree”. Depen- 
dendo das velocidades relativas dos dois processos (que dependem da complexidade relativa 
dos programas e de quanto tempo da CPU cada um recebeu), pode acontecer que grep esteja 
pronto para executar, mas não haja nenhuma entrada esperando por ele. Então, ele deve ser 
bloqueado até que a entrada esteja disponível. 

Quando um processo é bloqueado, isso acontece porque logicamente ele não pode con- 
tinuar, normalmente, porque está esperando uma entrada que ainda não está disponível. Tam- 
bém é possível que um processo que esteja conceitualmente pronto e capaz de executar, seja 
interrompido porque o sistema operacional decidiu alocar a CPU temporariamente para outro 
processo. Essas duas condições são completamente diferentes. No primeiro caso, a suspensão 
é inerente ao problema (você não pode processar a linha de comando do usuário até que ele a 
tenha digitado). No segundo caso, trata-se de um aspecto técnico do sistema (falta de CPUs 
suficientes para dar a cada processo seu próprio processador). Na Figura 2-2, vemos um dia- 
grama de estados mostrando os três estados em que um processo pode estar: 


Executando (realmente utilizando a CPU nesse instante) 


2. Pronto (executável; temporariamente parado para permitir que outro processo seja 
executado) 


3. Bloqueado (incapaz de executar até que algum evento externo aconteça) 


Logicamente, os dois primeiros estados são semelhantes. Nos dois casos, o processo 
está pronto para executar, só que no segundo não há nenhuma CPU disponível para ele, tem- 
porariamente. O terceiro estado é diferente dos dois primeiros porque o processo não pode 
executar, mesmo que a CPU não tenha mais nada a fazer. 


Executando ; 
1. O processo é bloqueado para entrada 


2. O escalonador seleciona outro processo 
3. O escalonador seleciona esse processo 
4. A entrada torna-se disponível 


Figura 2-2 Um processo pode estar em execução, bloqueado ou pronto. As transições entre 
esses estados são como mostradas. 
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Conforme mostrado, são possíveis quatro transições entre esses três estados. A tran- 
sição 1 ocorre quando um processo descobre que não pode continuar. Em alguns sistemas, 
o processo precisa executar uma chamada de sistema, block ou pause, para entrar no estado 
bloqueado. Em outros sistemas, incluindo o MINIX 3, quando um processo lê um pipe ou um 
arquivo especial (por exemplo, um terminal) e não há nenhuma entrada disponível, ele muda 
automaticamente do estado em execução para o estado bloqueado. 

As transições 2 e 3 são causadas pelo escalonador, que faz parte do sistema operacional, 
sem que o processo nem mesmo saiba a respeito delas. A transição 2 ocorre quando o escalo- 
nador decide que o processo em execução atuou por tempo suficiente e é hora de outro pro- 
cesso receber algum tempo da CPU. A transição 3 ocorre quando todos os outros processos já 
tiveram sua justa parte e é hora de o primeiro deles receber a CPU para executar novamente. 
O escalonamento — decidir qual processo deve ser executado, quando e por quanto tempo 
— é um assunto importante. Muitos algoritmos têm sido projetados para tentar equilibrar as 
demandas de eficiência concorrentes para o sistema como um todo e a imparcialidade para 
os processos individuais. Veremos o escalonamento e estudaremos alguns desses algoritmos 
posteriormente neste capítulo. 

A transição 4 ocorre quando o evento externo pelo qual um processo estava esperando 
acontece (por exemplo, a chegada de alguma entrada). Se nenhum outro processo estiver sen- 
do executado nesse instante, a transição 3 será ativada imediatamente e o processo começará 
a executar. Caso contrário, talvez ele tenha de esperar no estado pronto por alguns instantes, 
até que a CPU esteja disponível. 

Usando o modelo de processos, torna-se muito mais fácil pensar no que está ocorrendo 
dentro do sistema. Alguns processos executam programas que executam comandos digitados 
por um usuário. Outros processos fazem parte do sistema e executam tarefas como fazer re- 
quisições de serviços de arquivo ou gerenciar os detalhes da operação de um disco ou de uma 
unidade de fita. Quando ocorre uma interrupção de disco, o sistema pode tomar a decisão de 
parar de executar o processo corrente e executar o processo de disco, que estava bloqueado 
esperando essa interrupção. Dissemos “pode tomar a decisão”, porque isso depende das prio- 
ridades relativas do processo em execução e do processo do driver de disco. Mas a questão 
é que, em vez de pensar sobre interrupções, podemos pensar em processos de usuário, pro- 
cessos de disco, processos de terminal etc., que são bloqueados quando estão esperando algo 
acontecer. Quando o bloco de disco for lido ou o caractere digitado, o processo que estava 
esperando por isso é desbloqueado e é fica pronto para executar novamente. 

Essa visão dá origem ao modelo mostrado na Figura 2-3. Aqui, o nível mais baixo do 
sistema operacional é o escalonador, com uma variedade de processos sobre ele. Todo o tra- 
tamento de interrupção e os detalhes sobre como realmente iniciar e parar processos ficam 
ocultos no escalonador, que na verdade é bem pequeno. O restante do sistema operacional é 
estruturado elegantemente na forma de processos. O modelo da Figura 2-3 é utilizado no MI- 


Processos 


KETAN 


Escalonador 


Figura 2-3 A camada inferior de um sistema operacional estruturado em processos trata das 
interrupções e do escalonamento. Acima dessa camada estão os processos seqüenciais. 
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NIX 3. E claro que o “escalonador” não é o único elemento na camada inferior; também há 
suporte para tratamento de interrupções e para comunicação entre processos. Contudo, para 
uma primeira abordagem, isso serve para mostrar a estrutura básica. 


Implementação de processos 


Para implementar o modelo de processos, o sistema operacional mantém uma tabela (um 
array de estruturas), chamada tabela de processos, com uma entrada por processo. (Alguns 
autores chamam essas entradas de bloco de controle de processo.) Essa entrada contém in- 
formações sobre o estado do processo, sobre seu contador de programa, sobre o ponteiro da 
pilha, sobre a alocação de memória, sobre o status de seus arquivos abertos, suas informações 
de contabilidade e de escalonamento, alarmes e outros sinais, e tudo mais sobre o processo, as 
quais devem ser salvas quando o processo muda do estado em execução para pronto, a fim de 
que ele possa ser reiniciado posteriormente como se nunca tivesse sido interrompido. 

No MINIX 3, a comunicação entre processos, o gerenciamento da memória e o geren- 
ciamento de arquivos são tratados por módulos separados dentro do sistema, de modo que a 
tabela de processos é subdividida, com cada módulo mantendo os campos de que precisa. A 
Figura 2-4 mostra alguns dos campos mais importantes. Os campos da primeira coluna são 
os únicos relevantes para este capítulo. As outras duas colunas são fornecidas apenas para dar 
uma idéia das informações necessárias para outras partes no sistema. 


Núcleo 


Registradores 

Contador de programa 
Palavra de status do programa 
Ponteiro da pilha 

Estado do processo 
Prioridade de escalonamento 
corrente 

Prioridade máxima da 
escalonamento 

Tiques de escalonamento 
restantes 

Tamanho do quantum 

Tempo de CPU usado 
Ponteiros da fila de mensagens 
Bits de sinais pendentes 

Bits de flag 

Nome do processo 


Gerenciamento de processos 


Ponteiro para o segmento de 
texto 

Ponteiro para o segmento de 
dados 

Ponteiro para o segmento bss 
Status de saída 

Status de sinal 

ID do processo 

Processo pai 

Grupo do processo 

Tempo de CPU dos filhos 
UID real 

UID efetivo 

GID real 

GID efetivo 

Informações de arquivo para 
compartilhar texto 

Mapas de bits de sinais 
Vários bits de flag 

Nome do processo 


Gerenciamento de arquivos 


Máscara UMASK 
Diretório raiz 

Diretório de trabalho 
Descritores de arquivo 

Id real 

UID efetivo 

GID real 

GID efetivo 

tty de controle 

Área de salvamento para 
leitura/escrita 
Parâmetros da chamada de 
sistema 

Bits de flag 


Figura 2-4 Alguns campos da tabela de processos do MINIX 3. Os campos são distribuídos 
pelo núcleo, pelo gerenciador de processos e pelo sistema de arquivos. 


Agora que já vimos a tabela de processos, é possível explicar um pouco mais como a 
ilusão de múltiplos processos sequenciais é mantida em uma máquina com uma única CPU 
e muitos dispositivos de E/S. Tecnicamente, o texto a seguir é uma descrição de como o 
escalonador da Figura 2-3 funciona no MINIX 3, mas a maioria dos sistemas operacionais 
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modernos funciona basicamente da mesma maneira. Associada a cada classe de dispositivo 
de E/S (por exemplo, disquetes, discos rígidos, temporizadores, terminais), existe uma estru- 
tura de dados em uma tabela chamada de tabela de descritores de interrupção. A parte mais 
importante de cada entrada nessa tabela é chamada de vetor de interrupção. Ele contém 
o endereço da rotina de tratamento do serviço de interrupção. Suponha que o processo do 
usuário 23 esteja sendo executado, quando ocorre uma interrupção de disco. O contador de 
programa, a palavra de status do programa e, possivelmente, um ou mais registradores, são 
colocados na pilha (corrente) pelo hardware de interrupção. Então, o computador salta para o 
endereço especificado no vetor de interrupção de disco. Isso é tudo que o hardware faz. Daí 
em diante, fica por conta do software. 

A rotina do serviço de interrupção começa salvando todos os registradores na entrada da 
tabela de processos do processo corrente. O número do processo corrente e um ponteiro para 
sua entrada são mantidos em variáveis globais para que possam ser localizados rapidamente. 
Então, as informações postas na pilha pela interrupção são removidas e o ponteiro da pilha 
é configurado para uma pilha temporária, utilizada pela rotina de tratamento de processos. 
Ações como salvar os registradores e configurar o ponteiro da pilha não podem nem mesmo 
ser expressas em linguagens de alto nível, como C; portanto, elas são executadas por uma 
pequena rotina em linguagem assembly. Quando essa rotina termina, ela chama uma função 
em C para fazer o restante do trabalho para esse tipo específico de interrupção. 

A comunicação entre processos no MINIX 3 ocorre por meio de mensagens; portanto, 
o próximo passo é construir uma mensagem para ser enviada para o processo de disco, o qual 
será bloqueado para esperar por ela. A mensagem informa que ocorreu uma interrupção, para 
distingui-la das mensagens de processos de usuário solicitando a leitura de blocos de disco e 
coisas semelhantes. O estado do processo de disco agora é alterado de bloqueado para pronto 
e o escalonador é chamado. No MINIX 3, os processos podem ter prioridades diferentes, para 
fornecer um serviço melhor para as rotinas de tratamento de dispositivo de E/S do que para os 
processos de usuário, por exemplo. Se o processo de disco agora for o processo executável de 
prioridade mais alta, ele será escalonado para execução. Se o processo que foi interrompido 
é igualmente importante ou mais, então ele será escalonado para executar novamente e o pro- 
cesso de disco terá de esperar alguns instantes. 

De qualquer modo, a função em C ativada pelo código de interrupção em linguagem 
assembly retorna nesse momento e esse código carrega os registradores e o mapa da memória 
do processo agora corrente e inicia sua execução. O tratamento e o escalonamento de inter- 
rupções estão resumidos na Figura 2-5. Vale notar que os detalhes variam ligeiramente de um 
sistema para outro. 


1. O hardware empilha o contador de programa 

2. O hardware carrega um novo contador de programa a partir do vetor de interrupção. 

3. A rotina em linguagem assembly salva os registradores. 

4. A rotina em linguagem assembly configura a nova pilha. 

5. O serviço de interrupção em linguagem C constrói e envia a mensagem. 

6. O código de passagem de mensagens marca como pronto o destinatário da mensagem em espera. 
7. O escalonador decide qual processo vai ser executado em seguida. 

8. A rotina em linguagem C retorna para o código em linguagem assembly. 

9. A rotina em linguagem assembly inicia o novo processo corrente. 


Figura 2-5 Esqueleto do que faz o nível mais baixo do sistema operacional quando ocorre 
uma interrupção. 


78 


SISTEMAS OPERACIONAIS 


2.1.7 Threads 


Nos sistemas operacionais tradicionais, cada processo tem um espaço de endereçamento e 
um único fluxo de controle. Na verdade, essa é praticamente a definição de processo. Con- 
tudo, fregiientemente existem situações em que é desejável ter vários fluxos de controle no 
mesmo espaço de endereçamento, executando quase em paralelo, como se fossem processos 
separados (exceto quanto ao espaço de endereçamento compartilhado). Normalmente, esses 
fluxos de controle são chamados de threads, embora algumas pessoas os chamem de pro- 
cessos leves. 

Uma maneira de “enxergar” um processo é como um modo de agrupar recursos rela- 
cionados. Um processo tem um espaço de endereçamento contendo texto e dados do progra- 
ma, assim como outros recursos. Esses recursos podem incluir arquivos abertos, processos 
filhos, alarmes pendentes, rotinas de tratamento de sinal, informações de contabilização e 
muito mais. Colocando-os juntos na forma de um processo, eles podem ser gerenciados 
mais facilmente. 

O outro conceito que um processo tem é o de fluxo de execução, normalmente deno- 
minado apenas por thread. Uma thread tem um contador de programa que controla qual 
instrução vai ser executada. Ela possui registradores, os quais contêm suas variáveis de tra- 
balho correntes. Possui uma pilha, que contém o histórico de execução, com um bloco para 
cada função chamada, mas das quais ainda não houve retorno. Embora uma thread deva ser 
executada em algum processo, a thread e seu processo são conceitos diferentes e podem ser 
tratados separadamente. Os processos são usados para agrupar recursos; as threads são as 
entidades programadas para execução na CPU. 

O que as threads acrescentam no modelo de processo é o fato de permitir que várias 
execuções ocorram no mesmo ambiente de processo de forma bastante independente umas da 
outras. Na Figura 2-6(a), vemos três processos tradicionais. Cada processo tem seu próprio 
espaço de endereçamento e uma única thread de controle. Em contraste, na Figura 2-6(b), ve- 
mos um único processo com três threads de controle. Embora, nos dois casos, tenhamos três 
threads, na Figura 2-6(a) cada uma delas opera em um espaço de endereçamento diferente, 
enquanto na Figura 2-6(b) as três compartilham o mesmo espaço de endereçamento. 

Como exemplo de onde múltiplas threads poderiam ser utilizadas, considere um pro- 
cesso navegador web. Muitas páginas web contêm diversas imagens pequenas. Para cada 
imagem em uma página web, o navegador deve estabelecer uma conexão separada com o 
site de base da página e solicitar a imagem. Muito tempo é gasto no estabelecimento e na 
liberação de todas essas conexões. Com múltiplas threads dentro do navegador, várias ima- 


Processo 1 Processo 1 Processo 1 Processo 
Espaço 
de usuário 
Thread Thread 
Espaço [ A! 
de deled Núcleo Núcleo 


(a) (b) 


Figura 2-6 (a) Três processos, cada um com uma thread. (b) Um processo com três threads. 
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gens podem ser solicitadas ao mesmo tempo, na maioria dos casos aumentando bastante o 
desempenho, pois com pequenas imagens o fator limitante é o tempo de estabelecimento da 
conexão e não velocidade da linha de transmissão. 

Quando múltiplas threads estão presentes no mesmo espaço de endereçamento, alguns 
dos campos da Figura 2-4 não são por processo, mas por thread, de modo que é necessária 
uma tabela de segmentos separada, com uma entrada por thread. Entre os itens por thread es- 
tão o contador de programa, os registradores e o estado. O contador de programa é necessário 
porque, assim como os processos, as threads podem ser suspensas e retomadas. Os registra- 
dores são necessários porque quando as threads são suspensas, seus registradores devem ser 
salvos. Finalmente, assim como os processos, as threads podem estar no estado em execução, 
pronto ou bloqueado. A Figura 2-7 lista alguns itens por processo e por thread. 


Itens por processo Itens por thread 
Espaço de endereçamento Contador de programa 
Variáveis globais Registradores 
Arquivos abertos Pilha 


Processos filhos 

Alarmes pendentes 

Sinais e rotinas de tratamento de sinal 
Informações de contabilização 


Estado 


Figura 2-7 A primeira coluna lista alguns itens compartilhados por todas as threads em um 
processo. A segunda lista alguns itens privativos de cada thread. 


Em alguns sistemas, o sistema operacional não está ciente da existência das threads. 
Em outras palavras, elas são gerenciadas inteiramente em espaço de usuário. Quando uma 
thread está para ser bloqueada, por exemplo, ela escolhe e inicia seu sucessor, antes de parar. 
Vários pacotes de threads em nível de usuário são de uso comum, incluindo os pacotes PO- 
SIX P-threads e Mach C-threads. 

Em outros sistemas, o sistema operacional está ciente da existência de múltiplas threads 
por processo, de modo que, quando uma thread é bloqueada, o sistema operacional escolhe a 
próxima a executar, seja do mesmo processo, seja de um diferente. Para fazer o escalonamen- 
to, o núcleo precisa ter uma tabela de threads listando todas as threads presentes no sistema, 
análoga à tabela de processos. 

Embora essas duas alternativas possam parecer equivalentes, elas diferem considera- 
velmente no desempenho. A alternância entre threads é muito mais rápida quando o geren- 
ciamento de threads é feito em espaço de usuário do que quando é necessária uma chamada 
de sistema. Esse fato é um argumento forte para se fazer o gerenciamento de threads em 
espaço de usuário. Por outro lado, quando as threads são gerenciadas inteiramente em espaço 
de usuário e uma thread é bloqueada (por exemplo, esperando uma E/S ou o tratamento de 
um erro de página), o núcleo bloqueia o processo inteiro, pois ele nem mesmo está ciente da 
existência de outras threads. Esse fato, assim como outros, é um argumento para se fazer o 
gerenciamento de threads no núcleo (Boehm, 2005). Como consegiiência, os dois sistemas 
estão em uso e também foram propostos esquemas mistos (Anderson et al., 1992). 

Independentemente das threads serem gerenciadas pelo núcleo ou em espaço de usuá- 
rio, elas introduzem muitos outros problemas que deve ser resolvidos e que alteram consi- 
deravelmente o modelo de programação. Para começar, considere os efeitos da chamada de 
sistema fork. Se o processo pai tiver múltiplas threads, o filho também deverá tê-las? Se não, 
o processo poderá não funcionar corretamente, pois todas podem ser essenciais. 
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Entretanto, se o processo filho recebe tantas threads quanto o pai, o que acontece se 
uma for bloqueada em uma chamada read, digamos, a partir do teclado? Agora, duas threads 
estão bloqueadas no teclado? Quando uma linha é digitada, as duas threads obtêm uma cópia 
dela? Só o pai? Só o filho? O mesmo problema existe com conexões de rede abertas. 

Outra classe de problemas está relacionada ao fato das threads compartilharem muitas 
estruturas de dados. O que acontece se uma thread fecha um arquivo enquanto outra ainda 
está lendo esse arquivo? Suponha que uma thread perceba que há muito pouca memória e co- 
mece a alocar mais memória. Então, no meio do caminho, ocorre uma alternância de threads 
e a nova thread também percebe que há pouca memória e também começa a alocar mais me- 
mória. A alocação acontece uma ou duas vezes? Em quase todos os sistemas que não foram 
projetados considerando threads, as bibliotecas (como a função de alocação de memória) não 
são reentrantes e causarão uma falha se for feita uma segunda chamada enquanto a primeira 
ainda estiver ativa. 

Outro problema está relacionado com o informe de erros. No UNIX, após uma chamada 
de sistema, o status da chamada é colocado em uma variável global, errno. O que acontecerá 
se uma thread fizer uma chamada de sistema e, antes que possa ler errno, outra thread fizer 
uma chamada de sistema, apagando o valor original? 

Em seguida, considere os sinais. Alguns sinais são logicamente específicos a uma thre- 
ad, enquanto outros, não. Por exemplo, se uma thread chama alarm, faz sentido o sinal resul- 
tante ir para a thread que fez a chamada. Quando o núcleo está ciente das threads, ele normal- 
mente pode garantir que a thread correta receba o sinal. Quando o núcleo não está ciente das 
threads, o pacote que as implementa deve monitorar os alarmes sozinho. Existe uma compli- 
cação adicional para as threads em nível de usuário, quando (como no UNIX) um processo só 
pode ter um alarme pendente por vez e várias threads chamam alarm independentemente. 

Outros sinais, como SIGINT, iniciado pelo teclado, não são específicos de uma thread. 
Quem deve capturá-los? Uma thread específica? Todas as threads? Uma thread recentemente 
criada? Cada uma dessas soluções tem problemas. Além disso, o que acontece se uma thread 
altera as rotinas de tratamento de sinal sem informar as outras threads? 

Um último problema introduzido pelas threads é o gerenciamento da pilha. Em muitos 
sistemas, quando ocorre estouro da pilha, o núcleo apenas fornece mais pilha automaticamen- 
te. Quando um processo tem múltiplas threads, ele também deve ter múltiplas pilhas. Se o 
núcleo não estiver ciente de todas essas pilhas, ele não poderá aumentá-las automaticamente 
em caso de falta de pilha. Na verdade, ele nem mesmo percebe que uma falha de memória 
está relacionada com o crescimento da pilha. 

Certamente esses problemas não são insuperáveis, mas eles mostram que apenas intro- 
duzir threads em um sistema existente, sem um reprojeto substancial do sistema, não funcio- 
nará. No mínimo, a semântica das chamadas de sistema tem de ser redefinidas e as bibliotecas 
precisam ser reescritas. E todas essas coisas devem ser feitas de tal maneira que permaneçam 
compatíveis com os programas já existentes, para o caso limite de um processo com uma 
só thread. Para obter informações adicionais sobre threads, consulte Hauser et al. (1993) e 
Marsh et al. (1991). 


COMUNICAÇÃO ENTRE PROCESSOS 


Fregiientemente, os processos precisam se comunicar com outros processos. Por exemplo, no 
shell, em um pipe a saída do primeiro processo deve ser passada para o segundo processo e 
assim sucessivamente, em segiiência. Portanto, há necessidade de comunicação entre os pro- 
cessos, preferivelmente de uma maneira bem-estruturada que não utilize interrupções. Nas 
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seções a seguir, veremos alguns problemas relacionados à comunicação entre processos ou 
também denominados de mecanismos de IPC, do inglês, InterProcess Communication. 

Existem três problemas aqui. O primeiro foi mencionado anteriormente: como um 
processo pode passar informações para outro. O segundo tem a ver com como garantir que 
dois ou mais processos não interfiram um com outro quando envolvidos em atividades crí- 
ticas (suponha dois processos tentando alocar os últimos 1 MB de memória). O terceiro diz 
respeito ao sequenciamento adequado quando estão presentes dependências: se o processo A 
produz dados e o processo B os imprime, B tem de esperar até que A tenha produzido alguns 
dados, antes de começar a imprimir. Examinaremos esses problemas mais detalhadamente 
nesta seção. 

Também é importante mencionar que dois desses problemas se aplicam igualmente 
bem as threads. O primeiro — a passagem de informações — é fácil para as threads, pois elas 
compartilham um espaço de endereçamento comum (as threads em diferentes espaços de en- 
dereçamento que precisam se comunicar são classificadas como pertencentes à comunicação 
de processos). Entretanto, os outros dois — impedir que um atrapalhe o outro e o seqiiencia- 
mento adequado — também se aplicam as threads. Os mesmos problemas existem e as mes- 
mas soluções se aplicam. A seguir, discutiremos o problema no contexto dos processos, mas 
lembre-se de que os mesmos problemas e as soluções também se aplicam às threads. 


2.2.1 Condições de corrida 


Em alguns sistemas operacionais, os processos que estão trabalhando juntos podem compar- 
tilhar algum armazenamento comum onde cada um deles pode ler e escrever. O armazena- 
mento compartilhado pode estar na memória principal (possivelmente em uma estrutura de 
dados do núcleo) ou pode ser um arquivo; a localização exata do compartilhamento não muda 
a natureza da comunicação nem os problemas que surgem. Para ver como a comunicação 
entre processos funciona na prática, consideraremos um exemplo simples, mas comum: um 
spooler de impressão. Quando um processo quer imprimir um arquivo, ele insere o nome do 
arquivo em um diretório de spooler especial. Outro processo, o daemon de impressora, 
verifica periodicamente se há arquivos a serem impressos e, se houver, os imprime e, então, 
remove seus nomes do diretório. 

Imagine que nosso diretório de spooler tenha um grande número de entradas, numera- 
das como 0, 1, 2, ..., cada uma capaz de conter um nome de arquivo. Imagine também que 
haja duas variáveis compartilhadas: out, que aponta para o próximo arquivo a ser impresso; 
e in, que aponta para a próxima entrada livre no diretório. Essas duas variáveis poderiam ser 
mantidas em um arquivo de duas palavras, disponível para todos os processos. Em certo ins- 
tante, as entradas O a 3 estão livres (os arquivos já foram impressos) e as entradas 4 a 6 estão 
ocupadas (com os nomes dos arquivos a serem impressos). Mais ou menos simultaneamente, 
os processos A e B decidem que desejam colocar um arquivo na fila de impressão. Essa situa- 
ção é mostrada na Figura 2-8. 

Nas situações onde a lei de Murphy é aplicável, poderia acontecer o seguinte. O pro- 
cesso A lê in e armazena o valor 7 em uma variável local chamada next free slot. Exatamente 
nesse momento, ocorre uma interrupção de relógio e o sistema operacional decide que o 
processo A executou por tempo suficiente e, então, troca para o processo B. O processo B 
também lê in e também obtém o valor 7, de modo que armazena o nome de seu arquivo na 
entrada 7 e atualiza in para que seja 8. Então, ele segue adiante e faz outras coisas. 


* Se algo pode dar errado, dará. 
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Diretório 
de spooler 


Processo A 


Processo B 


1A 


Figura 2-8 Dois processos querem acessar uma área de memória compartilhada ao mesmo 
tempo. 


Finalmente, o processo A é executado novamente, começando a partir do lugar onde 
parou. Ele examina next_free_slot, encontra o valor 7, e escreve seu nome de arquivo nessa 
entrada, apagando o nome que o processo B acabou de colocar ali. Em seguida, ele calcula 
next_free_slot + 1, o que dá 8, e configura in como 8. Agora, o diretório de spooler está in- 
ternamente consistente; portanto, o daemon de impressora não notará nada de errado, mas o 
processo B nunca receberá nenhuma saída. O usuário B ficará na sala da impressora por mui- 
to tempo, esperando ansiosamente pela saída que nunca virá. Situações como essa, em que 
dois ou mais processos lêem e escrevem dados compartilhados e o resultado final depende 
da ordem de quem precisamente executa, e quando, são chamadas de condições de corrida 
(race conditions). Depurar programas contendo condições de corrida não é nada divertido. Os 
resultados da maioria dos testes são corretos, mas, de vez em quando, acontece algo estranho 
e inexplicável. 


Seções críticas 


Como evitamos as condições de corridas? O segredo para evitar problemas aqui e em muitas 
outras situações envolvendo memória compartilhada, arquivos compartilhados e tudo mais 
compartilhado é encontrar alguma maneira de proibir que mais de um processo leia e modifi- 
que dados compartilhados ao mesmo tempo. Em outras palavras, precisamos de uma exclu- 
são mútua — uma maneira de garantirmos que, se um processo estiver utilizando um arquivo 
compartilhado, ou uma variável compartilhada, outros processos sejam impedidos de fazer a 
mesma coisa. O problema anterior ocorreu porque o processo B começou a utilizar uma das 
variáveis compartilhadas antes que o processo A tivesse terminado de trabalhar com ela. A 
escolha das operações primitivas apropriadas para obter a exclusão mútua é um problema de 
projeto importante em qualquer sistema operacional e é um assunto que examinaremos agora 
detalhadamente. 

O problema de evitar as condições de corrida também pode ser formulado de uma ma- 
neira abstrata. Parte do tempo, um processo fica ocupado fazendo cálculos internos e outras 
coisas que não causam condições de corrida. Entretanto, às vezes, um processo pode estar 
acessando memória compartilhada ou arquivos compartilhados. Essa parte do programa, em 
que a memória compartilhada é acessada, é chamada de região crítica ou seção crítica. Se 
pudéssemos organizar as coisas de tal modo que dois processos jamais estivessem em suas 
regiões críticas ao mesmo tempo, poderíamos evitar as condições de corrida. 
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Embora esse requisito evite as condições de corrida, isso não é suficiente para ter pro- 
cessos paralelos cooperando correta e efetivamente, utilizando dados compartilhados. Preci- 
samos que quatro condições sejam válidas para termos uma boa solução: 


1. Dois processos não podem estar simultaneamente dentro de uma região crítica. 


2. Nenhuma suposição pode ser feita sobre as velocidades ou sobre o número de 
CPUs. 


3. Nenhum processo executando fora de sua região crítica pode bloquear outros pro- 
cessos. 


4. Nenhum processo deve ter que esperar eternamente para entrar em sua região crí- 
tica. 


O comportamento que queremos aparece na Figura 2-9. Aqui, o processo A entra na sua 
região crítica no tempo T,. Pouco depois, no tempo T,, o processo B tenta entrar na sua região 
crítica, mas falha, porque outro processo já está executando sua região crítica e só permitimos 
um por vez. Consegiientemente, B é suspenso temporariamente, até o tempo T,, quando A sai 
da região crítica, permitindo que B entre imediatamente. Finalmente, B sai (no tempo T,) e 
voltamos à situação original, sem nenhum processo em sua região crítica. 


A entra na região crítica 


/ A sai da região crítica 


Processo A 
I l l I 
l | l I E 
i | B tenta entrar | B entra na | B sai da 
na região região crítica região crítica 
l l crítica l l 
I 1/ l I E 
I l 
Processo B T i eeessssssassoosesesecesososssssoseeol 
I | y I l 
1 1 B bloqueado ı 1 
T, T, 3 T; 


Tempo ————> 


Figura 2-9 Exclusão mútua usando regiões críticas. 


Exclusão mútua com espera ativa 


Nesta seção, examinaremos várias propostas para obter exclusão mútua, para que, enquanto 
um processo está ocupado atualizando a memória compartilhada em sua região crítica, ne- 
nhum outro processo entre em sua região crítica e cause problemas. 


Desativando interrupções 


A solução mais simples é fazer cada processo desativar todas as interrupções imediatamente 
após entrar em sua região crítica e reativá-las imediatamente após sair dela. Com as interrup- 
ções desativadas, nenhuma interrupção de relógio pode ocorrer. Afinal, a CPU só alterna de 
um processo para outro como resultado de interrupções de relógio ou de outras interrupções, 
e com as interrupções desativadas não haverá troca para outro processo. Assim, quando um 
processo tiver desativado as interrupções, ele poderá examinar e atualizar a memória compar- 
tilhada sem medo de que qualquer outro processo intervenha. 
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Geralmente, essa estratégia é pouco atraente, pois não é aconselhável dar a processos de 
usuário o poder de desativar interrupções. Suponha que um deles fizesse isso e nunca mais as 
ativasse novamente. Isso poderia ser o fim do sistema. Além disso, se a máquina for um mul- 
tiprocessador, com duas ou mais CPUs, a desativação das interrupções afeta apenas a CPU 
que executou a instrução de desativação. As outras continuarão executando e poderão acessar 
a memória compartilhada. 

Por outro lado, fregiientemente é conveniente que o próprio núcleo desative interrup- 
ções para algumas instruções, enquanto está atualizando variáveis ou listas. Se ocorresse 
uma interrupção, por exemplo, enquanto a lista de processos prontos estivesse em um estado 
inconsistente, poderiam ocorrer condições de corrida. A conclusão é: desativar interrupções 
é frequentemente uma técnica útil dentro do sistema operacional em si, mas não é apropriada 
como um mecanismo de exclusão mútua geral para processos de usuário. 


Variáveis do tipo trava 


Como uma segunda tentativa, vamos procurar uma solução de software. Considere o fato 
de ter uma única variável (trava*) compartilhada, inicialmente com o valor 0. Quando um 
processo quer entrar em sua região crítica, ele primeiro testa o valor da variável trava. Se a 
trava for 0, o processo o configurará como 1 e entrará na região crítica. Se a trava já for 1, o 
processo apenas esperará até que ele se torne O. Assim, O significa que nenhum processo está 
em sua região crítica e 1 significa que algum processo está em sua região crítica. 

Infelizmente, essa idéia contém exatamente a mesma falha fatal que vimos no diretório 
de spooler. Suponha que um processo leia a trava e veja que ela é 0. Antes que ele possa 
configurar a trava como 1, outro processo é selecionado para execução, começa a executar e 
configura a trava como 1. Quando o primeiro processo for executado novamente, ele também 
configurará a trava como 1 e os dois processos estarão em suas regiões críticas ao mesmo 
tempo. 

Agora, você pode achar que poderíamos evitar esse problema lendo primeiro o valor 
da trava e, então, verificando-o novamente, imediatamente antes de armazenar nela, mas na 
verdade isso não ajuda. A condição de corrida agora ocorrerá se o segundo processo modifi- 
car a trava imediatamente depois que o primeiro processo tiver acabado de fazer sua segunda 
verificação. 


Alternância estrita 


Uma terceira estratégia para o problema da exclusão mútua aparece na Figura 2-10. Esse 
trecho de programa, como a maioria dos outros que aparecem neste livro, está escrito em C. 
A linguagem C foi escolhida aqui, porque os sistemas operacionais reais normalmente são 
escritos em C (ou, ocasionalmente, em C++), mas quase nunca em linguagens como Java. A 
linguagem C é poderosa, eficiente e previsível, características fundamentais para se escrever 
sistemas operacionais. A linguagem Java, por exemplo, não é previsível, pois pode ocorrer 
falta de capacidade de armazenamento em um momento crítico e o mecanismo de coletor de 
lixo ser ativado em uma hora inoportuna. Isso não acontece em C, pois não há coleta de lixo 
nessa linguagem. Uma comparação quantitativa das linguagens C, C++, Java e outras quatro 
linguagens é dada em Prechelt (2000). 

Na Figura 2-10, a variável inteira turn, inicialmente com o valor 0, controla de quem é a 
vez de entrar na região crítica e examinar ou atualizar a memória compartilhada. Inicialmen- 
te, o processo 0 inspeciona turn, descobre que é O e entra em sua região crítica. O processo 1 


* N. de R.T.: O termo trava tem se popularizado como tradução para o termo original, em inglês, lock. 
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também descobre que ela é O e, portanto, entra em um laço fechado, testando continuamente 
turn para ver quando ela se torna 1. Testar uma variável continuamente até que algum valor 
apareça é chamado de espera ativa (busy waiting). Normalmente, isso deve ser evitado, pois 
desperdiça tempo de CPU. Somente quando há uma expectativa razoável de que a espera seja 
breve é que a espera ativa é utilizada. Uma trava que utiliza espera ativa é chamada de trava 
giratória (spin lock). 


while (TRUE) ( while (TRUE) ( 
while (turn != 0) ; /* lago */ while (turn != 1); /* laço */ 
critical region(); critical region(); 
turn = 1; turn=0; 
noncritical region(); noncritical region(); 
) ) 


(a) (b) 


Figura 2-10 Uma solução proposta para o problema da região crítica. (a) Processo 0. (b) 
Processo 1. Nos dois casos, observe os pontos e vírgulas terminando as instruções while. 


Quando o processo O sai da região crítica, ele configura turn como 1, permitindo que o 
processo 1 entre em sua região crítica. Suponha que o processo 1 termine de trabalhar em sua 
região crítica rapidamente, de modo que os dois processos estejam em suas regiões não-críti- 
cas, com turn configurada como 0. Agora, o processo 0 executa seu laço inteiro rapidamente, 
saindo de sua região crítica e configurando turn como 1. Nesse ponto, turn é 1 e os dois pro- 
cessos estão sendo executados em suas regiões não-críticas. 

Repentinamente, o processo 0 acaba de trabalhar na sua região não-crítica e volta ao 
início de seu laço. Infelizmente, ele não tem permissão para entrar na sua região crítica agora, 
pois turn está configurada como 1 e o processo 1 está ocupado com sua região não-crítica. Ele 
fica preso em seu laço while, até que o processo 1 configure turn como 0. Em outras palavras, 
a utilização de turnos alternados de uso não é uma boa idéia quando um dos processos é mui- 
to mais lento do que o outro. 

Essa situação viola a condição 3 estabelecida anteriormente: o processo 0 está sendo 
bloqueado por um processo que não está em sua região crítica. Voltando ao diretório de spoo- 
ler já discutido, se a região crítica fosse associada com a leitura e com a gravação do diretório 
de spooler, o processo 0 não teria permissão para imprimir outro arquivo, porque o processo 
1 estaria fazendo outra coisa. 

Na verdade, essa solução exige que os dois processos alternem estritamente sua entrada 
nas suas regiões críticas, por exemplo, em arquivos de spool. Nenhum deles teria permissão 
para fazer dois spools seguidos. Embora esse algoritmo realmente evite todas as condições de 
corrida, na realidade não é um candidato sério como solução, pois viola a condição 3. 


A solução de Peterson 


Combinando a idéia de alternância com a idéia de variáveis de trava e variáveis de alerta, o 
matemático holandês T. Dekker foi o primeiro a imaginar uma solução de software para o 
problema da exclusão mútua que não exigisse uma alternância estrita. Para ver uma discussão 
sobre o algoritmo de Dekker, consulte Dijkstra (1965). 

Em 1981, G.L. Peterson descobriu um modo muito mais simples de obter a exclusão 
mútua, tornando obsoleta a solução de Dekker. O algoritmo de Peterson aparece na Figura 2- 
11. Esse algoritmo consiste em duas rotinas escritas em C ANSI, o que significa que devem ser 
fornecidos protótipos de função para todas as funções definidas e utilizadas. Entretanto, para 
economizar espaço, não mostraremos os protótipos neste exemplo nem nos subsegiientes. 
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tidefine FALSE O 
tdefine TRUE 1 


tdefine N 2 /* número de processos */ 
int turn; /* de quem é a vez? */ 
int interested[N]; /* todos os valores são inicialmente O (FALSE) */ 
void enter region(int process) /* o processo é O ou 1 */ 
{ 
int other; /* número do outro processo */ 
other = 1 — process; /* o oposto do processo */ 
interested[process] = TRUE; /* mostra que você está interessado */ 
turn = process; /* configura flag */ 


while (turn == process && interested[other] == TRUE) /* laço de espera */ ; 


) 


void leave region(int process) /* process: quem está saindo */ 


{ 
} 


Figura 2-11 Solução de Peterson para obter exclusão mútua. 


interested[process] = FALSE; /* indica saída da região crítica */ 


Antes de utilizar as variáveis compartilhadas (isto é, antes de entrar em sua região crí- 
tica), cada processo chama enter region com seu próprio número de processo, O ou 1, como 
parâmetro. Essa chamada fará com que ele espere, se necessário, até que seja seguro entrar. 
Depois que terminou de trabalhar com as variáveis compartilhadas, o processo chama leave . 
region para indicar que terminou e permitir que o outro processo entre, se assim o desejar. 

Vamos ver como essa solução funciona. Inicialmente, nenhum processo está em sua 
região crítica. Agora, o processo O chama enter region. Ele indica seu interesse escrevendo 
TRUE no elemento de array a si associado e configurando turn como 0. Como o processo 1 
não está interessado, enter region retorna imediatamente. Se o processo 1 agora chamar en- 
ter region, ele ficará parado até que interested[0] torne-se FALSE, um evento que só acontece 
quando o processo 0 chama leave region para sair da região crítica. 

Agora, considere o caso em que os dois processos chamam enter region quase simulta- 
neamente. Ambos armazenarão seu número de processo em turn. Qualquer que seja o arma- 
zenamento feito por último, é este que conta; o primeiro é perdido. Suponha que o processo 1 
armazene por último, de modo que turn é 1. Quando os dois processos chegarem na instrução 
while, o processo O a executa zero vezes e entra em sua região crítica. O processo 1 entra no 
laço e não entra em sua região crítica. 


A instrução TSL 


Agora, vamos ver uma proposta que exige uma pequena ajuda do hardware. Muitos compu- 
tadores, especialmente aqueles projetados com múltiplos processadores em mente, têm uma 
instrução 


TSL RX,LOCK 


(Test and Set Lock — testar e configurar trava) que funciona como segue: ela Iê o conteúdo da 
palavra de memória LOCK no registrador RX e, então, armazena um valor diferente de zero 
no endereço de memória LOCK. E garantido que as operações de leitura e de armazenamento 
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da palavra são indivisíveis — nenhum outro processador pode acessar a palavra de memória até 
que a instrução tenha terminado. A CPU que executa a instrução TSL bloqueia o barramento 
de memória, proibindo outras CPUs de acessar a memória até que ela tenha terminado. 

Para usar a instrução TSL, utilizaremos uma variável compartilhada, LOCK, para coor- 
denar o acesso à memória compartilhada. Quando LOCK é 0, qualquer processo pode confi- 
gurá-la como 1 utilizando a instrução TSL e, então, ler ou modificar a memória compartilha- 
da. Ao terminar, o processo configura LOCK novamente como 0, utilizando uma instrução 
move normal. 

Como essa instrução pode ser utilizada para impedir que dois processos entrem em suas 
regiões críticas simultaneamente? A solução aparece na Figura 2-12. Essa figura mostra uma 
sub-rotina de quatro instruções em uma linguagem assembly fictícia (mas típica). A primeira 
instrução copia o valor antigo de LOCK no registrador e depois configura LOCK como 1. En- 
tão, o valor antigo é comparado com 0. Se for diferente de zero, a trava já foi configurada; por- 
tanto, o programa apenas volta para o começo e faz o teste novamente. Cedo ou tarde, ele se 
tornará O (quando o processo que estiver correntemente em sua região crítica terminar de tra- 
balhar nela) e a sub-rotina retornará com a trava posicionada. Destravar é simples. O programa 
simplesmente armazena um valor 0 em LOCK. Nenhuma instrução especial é necessária. 


enter region: 


TSL REGISTER,LOCK | copia LOCK no registrador e configura LOCK como 1 

CMP REGISTER,HO | LOCK era zero? 

JNE ENTER REGION | se não era zero, LOCK estava configurada; portanto, 
entra no laço 

RET | retorna para quem fez a chamada; entrada na região 
crítica 

leave region: 
MOVE LOCK, HO | armazena o valor O em LOCK 
RET | retorna para quem fez a chamada 


Figura 2-12 Entrando e saindo de uma região crítica usando a instrução TSL. 


A solução para o problema da região crítica agora é simples. Antes de entrar em sua 
região crítica, um processo chama enter. region, que faz a espera ativa até que a trava esteja li- 
vre; em seguida, ele adquire a trava e retorna. Depois da região crítica, o processo chama lea- 
ve region, que armazena o valor O em LOCK. Como acontece em todas as soluções baseadas 
em regiões críticas, os processos devem chamar enter region e leave region nos momentos 
certos para o método funcionar. Se um processo trapacear, a exclusão mútua falhará. 


Sleep e Wakeup 


Tanto a solução de Peterson como a solução que utiliza TSL são corretas, mas ambas têm 
o defeito de exigir a espera ativa. Basicamente, o que essas soluções fazem é: quando um 
processo quer entrar em sua região crítica, ele verifica se a entrada é permitida. Se não for, o 
processo executa um laço fechado até que seja permitido entrar. 

Essa estratégia não apenas desperdiça tempo de CPU como também pode ter efeitos 
inesperados. Considere um computador com dois processos: H, com alta prioridade, e L, com 
baixa prioridade, os quais compartilham uma região crítica. As regras de escalonamento são 
tais que H é executado sempre que está no estado pronto. Em dado momento, com L em sua 
região crítica, H torna-se pronto para executar (por exemplo, uma operação de E/S termina). 
Agora, H começa a espera ativa, mas como L nunca é escalonado enquanto H está em exe- 
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cução, L nunca tem chance de sair da sua região crítica; portanto, H fica em um laço infinito. 
Essa situação às vezes é referida como problema da inversão de prioridade. 

Vamos ver agora algumas primitivas de comunicação entre processos que os bloqueiam, 
em vez de desperdiçar tempo de CPU, quando eles não podem entrar em suas regiões críticas. 
Uma das mais simples é o par sleep e wakeup. sleep é uma chamada de sistema que causa 
o bloqueio do processo que fez a chamada; isto é, ele é suspenso até que outro processo o 
desperte. A chamada de wakeup tem um parâmetro, o processo a ser despertado. Como alter- 
nativa, sleep e wakeup têm um parâmetro, um endereço de memória utilizado para fazer as 
instruções sleep corresponderem às instruções wakeup. 


O problema do produtor-consumidor 


Como um exemplo de uso dessas primitivas na prática, consideremos o problema do pro- 
dutor-consumidor (também conhecido como problema do buffer limitado). Dois proces- 
sos compartilham um buffer de tamanho fixo. Um deles, o produtor, coloca informações no 
buffer e o outro, o consumidor, as retira. (Também é possível generalizar o problema para m 
produtores e n consumidores, mas consideraremos apenas o caso de um produtor e um consu- 
midor, pois essa suposição simplifica as soluções.) 

O problema surge quando o produtor quer colocar um novo item no buffer, mas este já 
está cheio. A solução é o produtor ser bloqueado (sleep) esperando o consumidor remover um 
ou mais itens e permitir que o produtor seja desbloqueado (wakeup). De maneira semelhante, 
se o consumidor quiser remover um item do buffer este estiver vazio, ele bloqueará (sleep) até 
que o produtor coloque algo no buffer e o desbloqueie (wakeup). 

Essa estratégia parece bastante simples, mas leva aos mesmos tipos de condições de 
corrida que vimos anteriormente com o diretório de spooler. Para controlar o número de itens 
no buffer, precisaremos de uma variável, count. Se o número máximo de itens que o buffer 
pode armazenar for N, o código do produtor primeiro testará se count é N. Se for, o produtor 
bloqueará; se não for, o produtor adicionará um item e incrementará count. 

O código do consumidor é semelhante: primeiro testa count para ver se é O. Se for, blo- 
queará; se for diferente de zero, removerá um item e decrementará o contador. Cada um dos 
processos também testa para ver se o outro está bloqueado e se deve desbloqueá-lo. O código 
do produtor e do consumidor aparece na Figura 2-13. 

Para expressar chamadas de sistema como sleep e wakeup em C, as mostraremos como 
chamadas para funções de biblioteca. Elas não fazem parte da biblioteca C padrão, mas pre- 
sumivelmente estariam disponíveis em qualquer sistema que tivesse essas chamadas de siste- 
ma. As funções insert item e remove item, que não são mostradas, gerenciam a contabilidade 
da inserção e da retirada de itens do buffer. 

Voltemos agora à condição de corrida. Ela pode ocorrer porque o acesso a count é ir- 
restrito. A seguinte situação possivelmente pode ocorrer. O buffer está vazio e o consumidor 
acabou de ler count para ver se é O. Nesse instante, o escalonador decide parar temporiamente 
de executar o consumidor e começa a executar o produtor. O produtor insere um item no 
buffer, incrementa count e avisa que ela agora é 1. Deduzindo que count era O e, assim, que 
o consumidor deve estar dormindo (bloqueado), o produtor chama wakeup para acordá-lo 
(desbloquear). 

Infelizmente, o consumidor ainda não está logicamente bloqueado; portanto, o sinal 
para despertar (wakeup) é perdido. Na próxima vez que o consumidor for executado, ele tes- 
tará o valor de count lido anteriormente, verificará que ele é O e bloqueará. Cedo ou tarde, o 
produtor preencherá o buffer e também bloqueará. Ambos ficarão eternamente bloqueados. 

A essência do problema aqui é que um sinal para despertar, enviado para um processo 
que (ainda) não está bloqueado, é perdido. Se ele não fosse perdido, tudo funcionaria. Uma 
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#define N 100 /* número de entradas no buffer */ 
int count = O; /* número de itens no buffer */ 


void producer(void) 


{ 
int item; 
while (TRUE) { /* repete para sempre */ 
item = produce item(); /* gera o próximo item */ 
if (count == N) sleep(); /* se o buffer estiver cheio, bloqueia */ 
insert item(item); /* coloca item no buffer */ 
count = count + 1; /* incrementa a contagem de itens no buffer */ 


if (count == 1) wakeup(consumer); /* o buffer estava vazio? */ 


void consumer(void) 


{ 
int item; 
while (TRUE) { /* repete para sempre */ 
if (count == 0) sleep(); /* se o buffer estiver vazio, bloqueia */ 
item = remove_item(); /* retira item do buffer */ 
count = count — 1; /* decrementa a contagem de itens no buffer */ 
if (count == N — 1) wakeup(producer); /* o buffer estava cheio? */ 
consume item(item); /* imprime o item */ 


) 


Figura 2-13 O problema do produtor-consumidor com uma condição de corrida. 


correção rápida é modificar as regras para adicionar um bit de espera por despertar ao 
quadro geral. Quando um sinal para despertar for enviado para um processo que ainda está 
acordado (desbloqueado), esse bit é ativado. Posteriormente, quando o processo for ser blo- 
queado, e o bit de espera por despertar estiver ativado, ele será desativado, e o processo per- 
manecerá desbloqueado. O bit de espera por despertar é um cofrinho de sinais de despertar. 
Embora o bit de espera por despertar resolva o problema nesse exemplo simples, é fácil 
construir exemplos com três ou mais processos nos quais um bit de espera por despertar é 
insuficiente. Poderíamos fazer outro remendo e adicionar um segundo bit de espera por des- 
pertar ou quem sabe 8 bits, ou ainda 32 bits, mas, em princípio, o problema ainda existe. 


Semáforos 


Esta era a situação, quando E. W. Dijkstra (1965) sugeriu utilizar uma variável do tipo in- 
teiro para contar o número de sinais para despertar salvos para uso futuro. Em sua proposta, 
foi introduzido um novo tipo de variável, chamada semáforo. Um semáforo tem o valor 0, 
indicando que nenhum sinal para despertar foi salvo, ou um valor positivo, caso um ou mais 
sinais para despertar estivessem pendentes. 

Dijkstra propôs ter duas operações, down e up (que são generalizações de sleep e 
wakeup, respectivamente). Em um semáforo, a operação down verifica se o valor é maior que 
0. Se for, ele decrementa o valor (isto é, utiliza um sinal para despertar armazenado) e sim- 
plesmente continua. Se o valor for 0, o processo é colocado “para dormir” (bloqueado) sem 
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completar a operação down. Verificar o valor, alterá-lo e, possivelmente, ser bloqueado, tudo 
é feito como uma única e indivisível ação atômica. É garantido que, uma vez iniciada uma 
operação de semáforo, nenhum outro processo pode acessar o semáforo até que a operação 
tenha terminado ou sido bloqueada. Essa atomicidade é absolutamente essencial para resolver 
problemas de sincronismo e evitar condições de corrida. 

A operação up incrementa o valor do semáforo passado como parâmetro. Se um ou 
mais processos estavam bloqueados nesse semáforo, incapazes de completar uma operação 
down anterior, um deles é escolhido pelo sistema (aleatoriamente, por exemplo) e autorizado 
a completar sua operação down. Assim, depois de uma operação up em um semáforo conten- 
do processos bloqueados, o semáforo ainda será 0, mas haverá nele um processo bloqueado 
a menos. A operação de incrementar o semáforo e de despertar um processo também é in- 
divisível. Nenhum processo é bloqueado durante uma operação up, assim como, no modelo 
anterior, nenhum processo é bloqueado durante uma operação wakeup. 

A propósito, no artigo original de Dijkstra, ele utilizou os nomes P e V, em vez de 
down e up, respectivamente, mas como esses nomes não têm significado mnemônico para 
as pessoas que não falam holandês (e significado apenas marginal para aqueles que falam), 
utilizaremos os termos down e up. Esses termos foram introduzidos pela primeira vez na 
linguagem Algol 68. 


Resolvendo o problema do produtor-consumidor utilizando semáforos 


Os semáforos resolvem o problema do sinal para despertar perdido, como mostrado na Figura 
2-14. É fundamental que eles sejam implementados de maneira indivisível. A maneira normal 
é implementar up e down como chamadas de sistema, com o sistema operacional desativando 
brevemente todas as interrupções enquanto está testando o semáforo, atualizando-o e bloque- 
ando o processo, se necessário. Como todas essas ações precisam de apenas algumas instru- 
ções, não há nenhum prejuízo em desativar as interrupções. Se várias CPUs estiverem sendo 
utilizadas, cada semáforo deverá ser protegido por uma variável do tipo trava, com a instrução 
TSL usada para garantir que apenas uma CPU por vez examine o semáforo. Entenda que 
utilizar TSL para impedir que várias CPUs acessem o semáforo ao mesmo tempo é muito di- 
ferente da espera ativa por parte do produtor ou do consumidor, aguardando o outro esvaziar 
ou preencher o buffer. A operação de semáforo só levará alguns microssegundos, enquanto o 
produtor ou o consumidor poderá demorar um tempo arbitrariamente longo. 

Essa solução utiliza três semáforos: um chamado full, para contar o número de entradas 
que estão ocupadas, um chamado empty, para contar o número de entradas que estão livres, 
e um chamado mutex, para garantir que o produtor e o consumidor não acessem o buffer ao 
mesmo tempo. Inicialmente, full é O, empty é igual ao número de entradas no buffer e mutex 
é 1. Os semáforos inicializados com 1 e utilizados por dois ou mais processos para garantir 
que apenas um deles possa entrar em sua região crítica por vez, são chamados de semáforos 
binários. Se cada processo executa uma operação down imediatamente antes de entrar em 
sua região crítica e uma operação up imediatamente após sair dela, a exclusão mútua é ga- 
rantida. 

Agora que temos uma boa primitiva de comunicação entre processos à nossa disposição, 
vamos voltar e ver novamente a sequência de interrupção da Figura 2-5. Em um sistema que 
utiliza semáforos, a maneira natural de ocultar interrupções é ter um semáforo inicializado 
em 0, associado a cada dispositivo de E/S. Imediatamente após iniciar um dispositivo de E/S, 
o processo que está gerenciando executa uma operação down no semáforo associado, bloque- 
ando, assim, de imediato. Quando a interrupção ocorre, a rotina de tratamento de interrupção 
executa uma operação up nesse semáforo, a qual torna o processo relevante novamente pronto 
para executar. Nesse modelo, a etapa 6 da Figura 2-5 consiste em executar uma operação up 
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tdefine N 100 

typedef int semaphore; 
semaphore mutex = 1; 
semaphore empty = N; 
semaphore full = O; 


void producer(void) 
{ 


int item; 


while (TRUE) { 


item = produce_item(); 


down(&empty); 
down(&mutex); 


insert item(item); 


up(&mutex); 
up(&full); 


void consumer(void) 


{ 


int item; 


while (TRUE) { 
down(&full); 
down(&mutex); 


item = remove item(); 


up(&mutex); 
up(&empty); 


consume item(item); 


) 


/* número de entradas no buffer */ 

/* os semáforos são um tipo especial de inteiro */ 
/* controla o acesso à região crítica */ 

/* conta as entradas livres do buffer */ 

/* conta as entradas ocupadas do buffer */ 


/* TRUE é a constante 1 */ 

/* produz algo para colocar no buffer */ 

/* decrementa a contagem de entradas livres */ 

/* entra na região crítica */ 

/* coloca um novo item no buffer */ 

/* sai da região crítica */ 

/* incrementa a contagem de entradas ocupadas */ 


/* laço infinito */ 

/* decrementa a contagem de entradas ocupadas */ 
/* entra na região crítica */ 

/* retira item do buffer */ 

/* sai da região crítica */ 

/* incrementa a contagem de entradas livres */ 

/* faz algo com o item */ 


Figura 2-14 O problema do produtor-consumidor usando semáforos. 


no semáforo do dispositivo, para que na etapa 7 o escalonador possa executar o gerenciador 
de dispositivo. Naturalmente, se agora vários processos estiverem prontos, o escalonador po- 
derá optar por executar em seguida um processo ainda mais importante. Posteriormente, neste 
capítulo, veremos como o escalonamento é feito. 

No exemplo da Figura 2-14, utilizamos os semáforos, na realidade, de duas maneiras 
diferentes. Essa diferença é importante o suficiente para se tornar explícita. O semáforo mutex 
é utilizado para exclusão mútua. Ele é projetado para garantir que apenas um processo por 
vez leia ou grave no buffer e nas variáveis associadas. Essa exclusão mútua é exigida para 
evitar o caos. Na próxima seção, estudaremos mais a exclusão mútua e como obtê-la. 

A outra utilização de semáforos é para sincronização. Os semáforos full e empty são 
necessários para garantir que certas sequências de eventos ocorram ou não. Neste caso, eles 
garantem que o produtor pare de executar quando o buffer está cheio e o consumidor pare de 
executar quando o buffer está vazio. Esse uso é diferente da exclusão mútua. 
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2.2.6 


2.2.7 


Mutex 


Quando não é necessária a capacidade de contar do semáforo, às vezes é utilizada uma versão 
simplificada do semáforo, chamada de mutex. Os mutexes são bons apenas para gerenciar a 
exclusão mútua de algum recurso ou parte de código compartilhado. Sua implementação é 
fácil e eficiente, o que os torna particularmente úteis em nas implementações de threads em 
espaço de usuário. 

Um mutex é uma variável que pode ter dois estados: livre ou ocupado. Conseqiiente- 
mente, apenas 1 bit é exigido para representá-lo, mas, na prática, frequentemente é usado um 
valor inteiro, com O significando livre e todos os outros valores significando ocupado. Duas 
primitivas são usadas com os mutexes. Quando um processo (ou thread) precisa acessar uma 
região crítica, ele chama mutex lock. Se o mutex está correntemente livre (significando que 
a região crítica está disponível), a chamada é bem-sucedida e o processo que fez a chamada 
pode entrar na região crítica. 

Por outro lado, se o mutex está ocupado, o processo que fez a chamada é bloqueado até 
que o processo que se encontra na região crítica tenha terminado e chame mutex unlock. Se 
vários processos estiverem bloqueados no mutex, um deles será escolhido aleatoriamente e 
poderá entrar na região crítica. 


Monitores 


Com os semáforos, a comunicação entre processos parece fácil, certo? Esqueça. Examine de- 
tidamente a ordem das operações down antes da inserção ou da remoção de itens do buffer na 
Figura 2-14. Suponha que as duas operações down no código do produtor tivessem sua ordem 
invertida, de modo que o mutex fosse decrementado antes de empty e não depois. Se o buffer 
estivesse completamente cheio, o produtor seria bloqueado, com mutex configurado como 0. 
Conseqiientemente, na próxima vez que o consumidor tentasse acessar o buffer, ele executaria 
uma operação down em mutex, agora 0, e também seria bloqueado. Os dois processos perma- 
neceriam bloqueados para sempre e mais nenhum trabalho seria feito. Essa situação desastrosa 
é chamada de impasse (deadlock). Estudaremos os impasses detalhadamente no Capítulo 3. 

Esse problema foi apontado para mostrar como cuidadoso deve-se ser ao utilizar semá- 
foros. Um erro sutil e tudo vai por água abaixo. É como programar em linguagem assembly, 
só que pior, pois os erros são condições de corrida, impasses e outras formas de comporta- 
mento imprevisível e irreproduzível. 

Para tornar mais fácil escrever programas corretos, Brinch Hansen (1975) e Hoare 
(1974) propuseram uma primitiva de sincronismo de mais alto nível, chamada de monitor. 
Suas propostas diferiam ligeiramente, conforme descrito a seguir. Um monitor é um conjunto 
de rotinas, variáveis e estruturas de dados, todas agrupadas em um tipo especial de módu- 
lo ou pacote. Os processos podem chamar as rotinas presentes em um monitor sempre que 
quiserem, mas não podem acessar diretamente as estruturas de dados internas do monitor a 
partir das rotinas declaradas fora dele. Essa regra, normal nas linguagens orientadas a objetos 
modernas, como Java, era relativamente incomum em seu tempo, embora os objetos remon- 
tem à linguagem Simula 67. A Figura 2-15 ilustra um monitor escrito em uma linguagem 
imaginária, a pseudo-Pascal. 

Os monitores têm uma propriedade importante que os torna úteis para obter exclusão 
mútua: a qualquer instante, apenas um processo pode estar ativo em um monitor. Os monito- 
res são uma construção de linguagem de programação, de modo que o compilador sabe que 
eles são especiais e pode manipular chamadas para as rotinas do monitor de forma diferente 
de outras chamadas de procedimentos. Em geral, quando um processo chama uma rotina do 
monitor, suas primeiras instruções verificam se algum outro processo está ativo dentro do 
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monitor example 
integer i; 
condition c; 


procedure producer(x); 


end; 


procedure consumer(x); 


end; 
end monitor; 


Figura 2-15 Um monitor. 


monitor. Se assim for, o processo que fez a chamada será suspenso até que o outro processo 
tenha saído do monitor. Se nenhum outro processo estiver usando o monitor, o processo que 
fez a chamada poderá entrar. 

Cabe ao compilador implementar a exclusão mútua em entradas de monitor, mas uma 
maneira comum é utilizar um mutex ou um semáforo binário. Como é o compilador, e não o 
programador que faz preparativos para a exclusão mútua, é muito menos provável que algo dê 
errado. De qualquer modo, a pessoa que escreve o monitor não precisa saber como o compi- 
lador organiza a exclusão mútua. Basta saber que, transformando todas as regiões críticas em 
rotinas do monitor, nunca dois processos executarão suas regiões críticas ao mesmo tempo. 

Embora os monitores ofereçam uma maneira fácil de obter exclusão mútua, como vi- 
mos anteriormente, isso não é suficiente. Também precisamos de uma maneira de bloquear os 
processos quando eles não podem prosseguir. No problema do produtor-consumidor, é muito 
fácil colocar todos os testes de buffer cheio e buffer vazio em rotinas do monitor, mas como 
bloquear o produtor quando o buffer estiver cheio? 

A solução está na introdução de variáveis de condição, junto com duas operações so- 
bre elas, wait e signal. Quando uma rotina do monitor descobre que não pode continuar (por 
exemplo, o produtor encontra o buffer cheio), ela executa uma operação wait uma variável 
de condição, digamos, full. Essa ação causa o bloqueio do processo que fez a chamada. Ela 
também permite que outro processo, anteriormente proibido de entrar no monitor, agora 
entre. 

Esse outro processo, por exemplo, o consumidor, pode despertar seu parceiro que está 
bloqueado, executando uma operação signal na variável de condição que este está esperando. 
Para evitar a existência de dois processos simultaneamente ativos no monitor, precisamos de 
uma regra dizendo o que acontece após uma operação signal. Hoare propôs deixar o processo 
recentemente desbloqueado executar, suspendendo o outro. Brinch Hansen propôs refinar o 
problema, exigindo que um processo que execute uma operação signal deve sair do monitor 
imediatamente. Em outras palavras, uma instrução signal pode aparecer apenas como a ins- 
trução final em uma rotina do monitor. Utilizaremos a proposta de Brinch Hansen por ser 
conceitualmente mais simples e também mais fácil de implementar. Se uma operação signal é 
executada em uma variável de condição em que vários processos estão esperando, apenas um 
deles, determinado pelo escalonador do sistema, é desbloqueado. 

As variáveis de condição não são contadores. Elas não acumulam sinais para uso futuro, 
como fazem os semáforos. Assim, se uma variável de condição é sinalizada sem ninguém 
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esperando nela, o sinal é perdido. Em outras palavras, wait deve vir antes de signal. Essa regra 
torna a implementação muito mais simples. Na prática, isso não é problema, porque é fácil 
acompanhar o estado de cada processo com variáveis, se for necessário. Um processo que, 
de outro modo, poderia executar uma operação signal, poderá ver que essa operação não é 
necessária examinando as variáveis. 

Um esqueleto do problema do produtor-consumidor com monitores aparece, em pseu- 
do-Pascal, na Figura 2-15. A vantagem de usar pseudo-Pascal aqui é que a linguagem é pura 
e simples, seguindo exatamente o modelo de Hoare/Brinch Hansen. 


monitor ProducerConsumer 
condition full, empty; 
integer count; 


procedure insert(item: integer); 
begin 

if count = N then wait(full); 

insert item(item); 

count := count + 1; 

if count = 1 then signal(empty) 
end; 


function remove: integer; 
begin 
if count = O then wait(empty); 
remove = remove. item; 
count := count - 1; 
if count = N - 1 then signal(full) 
end; 


count := O; 
end monitor; 


procedure producer; 
begin 
while true do 
begin 
item = produce item; 
ProducerConsumer.inseri(item) 
end 
end; 


procedure consumer; 


begin 
while true do 
begin 
item = ProducerConsumer.remove; 
consume. item(item) 
end 
end; 


Figura 2-16 Um esboço da solução do problema do produtor-consumidor com monitores. 
Apenas uma rotina do monitor por vez está ativa. O buffer tem N entradas. 


CAPÍTULO 2 e PROCESSOS 95 


Você pode estar pensando que as operações wait e signal se parecem com sleep e 
wakeup, que, como vimos anteriormente, tinham condições de corrida. De fato, elas são 
muito parecidas, mas com uma diferença fundamental: sleep e wakeup falhavam porque, 
enquanto um processo estava sendo bloqueado, um outro já tentava desbloqueá-lo. Com os 
monitores, isso não acontece. A exclusão mútua automática em rotinas do monitor garante 
que se, digamos, o produtor existente dentro de uma rotina do monitor descobre que o buffer 
está cheio, ele poderá completar a operação wait sem precisar preocupar-se com a possibili- 
dade do escalonador trocar para o consumidor exatamente antes da operação wait terminar. O 
consumidor nem mesmo será autorizado a entrar no monitor até que a operação wait termine 
e o produtor seja identificado como não mais executável. 

Embora a linguagem pseudo-Pascal seja imaginária, algumas linguagens de programa- 
ção reais também suportam monitores, ainda que nem sempre na forma projetada por Hoare 
e Brinch Hansen. Uma dessas linguagens é Java. A linguagem Java é orientada a objetos, 
suporta threads em nível de usuário e também permite o agrupamento de métodos (proce- 
dimentos) em classes. Adicionando a palavra-chave synchronized em uma declaração de 
método, a linguagem Java garante que, quando qualquer thread tiver começado a executar 
esse método, nenhuma outra thread poderá realizar qualquer outro método synchronized 
nessa classe. 

Os métodos sincronizados em Java diferem dos monitores clássicos de uma maneira 
fundamental: a linguagem Java não tem variáveis de condição. Em vez disso, ela oferece dois 
métodos, wait e notify, que são equivalentes a sleep e wakeup, exceto que, quando usadas 
dentro de métodos sincronizados, elas não estão sujeitas às condições de corrida. 

Tornando automática a exclusão mútua de regiões críticas, os monitores tornaram a pro- 
gramação paralela muito menos sujeita a erros do que com semáforos. Mas eles também têm 
alguns inconvenientes. Não é à toa que a Figura 2-16 está escrita em pseudo-Pascal, em vez 
de C, como os outros exemplos deste livro. Como dissemos anteriormente, os monitores são 
um conceito de linguagem de programação. De algum modo, o compilador deve reconhecê- 
los e fazer preparativos para a exclusão mútua. C, Pascal e a maioria das outras linguagens 
não têm monitores; portanto, não é razoável esperar que seus compiladores imponham regras 
de exclusão mútua. De fato, como o compilador poderia saber quais rotinas pertencem a mo- 
nitores e quais não? 

Essas mesmas linguagens também não têm semáforos, mas é fácil adicioná-los: basta 
adicionar à biblioteca duas rotinas curtas em código assembly, para produzir as chamadas de 
sistema up e down. Os compiladores sequer precisam saber que elas existem. Naturalmente, 
os sistemas operacionais precisam saber da existência dos semáforos, mas, pelo menos se 
você tiver um sistema operacional baseado em semáforo, ainda poderá escrever os programas 
de usuário para ele em C ou C + + (ou mesmo em FORTRAN, se for masoquista). Com mo- 
nitores, você precisa de uma linguagem que os tenha incorporados. 

Outro problema dos monitores, e também dos semáforos, é que eles foram projetados 
para resolver o problema da exclusão mútua em uma ou mais CPUs que têm acesso a uma 
memória comum. Colocando os semáforos na memória compartilhada e protegendo-os com 
instruções TSL, podemos evitar as condições de corrida. Quando usamos um sistema distribu- 
ído, composto de várias CPUs, cada uma com sua própria memória privativa e conectadas por 
uma rede local, essas primitivas se tornão inaplicáveis. A conclusão é que os semáforos são 
de nível muito baixo e os monitores não são utilizáveis, exceto em umas poucas linguagens 
de programação. Além disso, nenhuma das primitivas oferece troca de informações entre 
máquinas. Algo mais é necessário. 
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2.2.8 Passagem de mensagens 


Esse algo mais é a passagem de mensagens. Esse método de comunicação entre processos 
utiliza duas primitivas, send e receive, as quais, como os semáforos e ao contrário dos moni- 
tores, são chamadas de sistema em vez de construções da linguagem. Como tal, elas podem 
ser facilmente colocadas em funções de biblioteca, como 


send(destination, &message); 


receive(source, &message); 


A primeira chamada envia uma mensagem para determinado destino, enquanto a segun- 
da recebe uma mensagem de determinada origem (ou de ANY, se o destinatário não se impor- 
tar). Se nenhuma mensagem estiver disponível, o destinatário é bloqueado até uma chegar. 
Como alternativa, ele pode retornar imediatamente com um código de erro. 


Questões de projeto para sistemas de passagem de mensagens 


Os sistemas de passagem de mensagens têm muitos problemas desafiadores e questões de 
projeto que não aparecem nos semáforos nem nos monitores, especialmente se os proces- 
sos que estão se comunicando estiverem em máquinas diferentes conectadas por uma rede. 
Por exemplo, mensagens podem ser perdidas na rede. Para evitar a perda de mensagens, 
o remetente e o destinatário podem concordar que, assim que a mensagem for recebida, o 
destinatário enviará de volta uma mensagem especial de reconhecimento ou confirmação 
(acknowledgement). Se o remetente não receber o sinal de reconhecimento dentro de certo 
intervalo de tempo (timeout), ele retransmitirá a mensagem. 

Agora, considere o que acontece se a mensagem em si é recebida corretamente, mas o 
sinal de reconhecimento é perdido. O remetente retransmitirá a mensagem; portanto, o desti- 
natário a receberá duas vezes. É fundamental que o destinatário possa diferenciar entre uma 
nova mensagem e a retransmissão de uma antiga. Normalmente, esse problema é resolvido 
colocando-se números em segiiência consecutivos em cada mensagem original. Se o destina- 
tário receber uma mensagem contendo o mesmo número de sequência da mensagem anterior, 
ele saberá que a mensagem é uma duplicata que pode ser ignorada. 

Os sistemas de mensagem também têm de lidar com a questão de como os processos 
são identificados, para que o processo especificado em uma chamada de send ou receive não 
seja ambíguo. A autenticação também é um problema nos sistemas de mensagem: como o 
cliente pode saber se está se comunicando com o verdadeiro servidor de arquivos e não com 
um impostor? 

Na outra extremidade do espectro, também há questões de projeto que são importantes 
quando o remetente e o destinatário estão na mesma máquina. Uma delas é o desempenho. 
Copiar mensagens de um processo para outro é sempre mais lento do que executar uma ope- 
ração de semáforo ou entrar em um monitor. Muito trabalho foi realizado no sentido de tornar 
a passagem de mensagens eficiente. Cheriton (1984), por exemplo, sugeriu limitar o tamanho 
da mensagem para algo que caiba nos registradores da máquina e, então, realizar a passagem 
da mensagem utilizando os registradores. 


O problema do produtor-consumidor com passagem de mensagens 


Vamos ver agora como o problema do produtor-consumidor pode ser resolvido com passa- 
gem de mensagens e nenhuma memória compartilhada. Uma solução aparece na Figura 2-17. 
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Supomos que todas as mensagens têm o mesmo tamanho e que as mensagens enviadas, mas 
ainda não recebidas, são automaticamente armazenadas em buffer pelo sistema operacional. 
Nessa solução, é utilizado um total de N mensagens, análogo às N entradas em um buffer de 
memória compartilhada. O consumidor começa enviando N mensagens vazias para o pro- 
dutor. Quando o produtor tem um item para enviar ao consumidor, ele pega uma mensagem 
vazia e envia de volta uma cheia. Dessa maneira, o número total de mensagens no sistema 
permanece constante com o tempo, de modo que elas podem ser armazenadas em uma quan- 
tidade de memória previamente conhecida. 

Se o produtor trabalhar mais rápido do que o consumidor, todas as mensagens serão 
usadas e o produtor será bloqueado esperando o consumidor enviar de volta uma mensagem 
vazia. Se o consumidor trabalhar mais rápido, então o inverso acontecerá: todas as mensagens 
estarão vazias, esperando o produtor enchê-las; o consumidor será bloqueado, esperando uma 
mensagem cheia. 


tdefine N 100 /* número de entradas no buffer */ 
void producer(void) 
{ 

int item; 


message m; /* buffer de mensagens */ 


while (TRUE) { 


item = produce_item(); /* produz algo para colocar no buffer */ 
receive(consumer, &m); /* espera a chegada de uma mensagem vazia */ 
build message(&m, item); /* constrói uma mensagem para enviar */ 
send(consumer, &m); /* envia item para o consumidor */ 


void consumer(void) 
{ 
int item, i; 
message m; 


for (i = 0; i < N; i++) send(producer, &m); /* envia N mensagens vazias */ 
while (TRUE) { 


receive(producer, &m); /* recebe a mensagem contendo o item */ 
item = extract_item(&m); /* extrai o item da mensagem */ 
send(producer, &m); /* envia de volta resposta vazia */ 
consume_item(item); /* faz algo com o item */ 


} 


Figura 2-17 O problema do produtor-consumidor com N mensagens. 


Muitas variantes são possíveis com passagem de mensagens. Para os principiantes, ve- 
jamos como as mensagens são endereçadas. Uma maneira é atribuir um endereço único a 
cada processo e fazer com que as mensagens sejam endereçadas a eles. Uma maneira diferen- 
te é inventar uma nova estrutura de dados, chamada de caixa de correio (mailbox). Uma cai- 
xa de correio é uma área capaz de armazenar um certo número de mensagens, normalmente 
especificado quando a caixa de correio é criada. Quando são utilizadas caixas de correio, os 
parâmetros de endereço nas chamadas de send e receive são caixas de correio e não proces- 
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2.3 


2.3.1 


sos. Quando um processo tenta fazer um envio para uma caixa de correio que está cheia, ele 
é suspenso até que uma mensagem seja removida dessa caixa de correio, dando espaço para 
a nova mensagem. 

Para o problema do produtor-consumidor, tanto o produtor como o consumidor pode- 
riam criar caixas de correio suficientemente grandes para conter N mensagens. O produtor 
enviaria mensagens contendo dados para a caixa de correio do consumidor e o consumidor 
enviaria mensagens vazias para a caixa de correio do produtor. Quando são utilizadas caixas 
de correio, o mecanismo de armazenamento é claro: a caixa de correio do destino contém as 
mensagens que foram enviadas para o processo de destino, mas que ainda não foram aceitas. 

O outro extremo do fato de ter caixas de correio é eliminar todo armazenamento. Quan- 
do essa estratégia é adotada, se a operação send é executada antes da operação receive, o pro- 
cesso que está fazendo o envio é bloqueado até que a operação receive aconteça, momento no 
qual a mensagem pode ser copiada diretamente do remetente para o destinatário, sem nenhum 
armazenamento intermediário. De maneira semelhante, se a operação receive é executada 
primeiro, o destinatário é bloqueado até que uma operação send aconteça. Essa estratégia é 
frequentemente conhecida como rendez-vous. Ela é mais fácil de ser implementada do que 
um esquema de mensagens armazenadas em buffer, mas é menos flexível, pois o remetente e 
o destinatário são obrigados a executar em cadência. 

Os processos que compõe o sistema operacional MINIX 3 em si utilizam o método de 
rendez-vous com mensagens de tamanho fixo para se comunicarem. Os processos de usuário 
também utilizam esse método para se comunicarem com componentes do sistema operacio- 
nal, embora o programador não veja isso, pois rotinas de biblioteca servem como interme- 
diárias das chamadas de sistema. A comunicação entre processos de usuário no MINIX 3 (e 
no UNIX) ocorre por intermédio de pipes, que são, efetivamente, caixas de correio. A única 
diferença real entre um sistema de mensagem com caixas de correio e o mecanismo de pipes 
é que os pipes não preservam os limites da mensagem. Em outras palavras, se um processo 
gravar 10 mensagens de 100 bytes em um pipe e outro processo ler 1.000 bytes desse pipe, o 
leitor receberá as 10 mensagens de uma vez. Com um verdadeiro sistema de mensagens, cada 
operação read deve retornar apenas uma mensagem. Naturalmente, se os processos concor- 
darem em sempre ler e gravar mensagens de tamanho fixo no pipe ou em finalizar cada men- 
sagem com um caractere especial (por exemplo, um avanço de linha), não haverá nenhum 
problema. 

A passagem de mensagens é usada normalmente nos sistemas de programação paralela. 
Por exemplo, um sistema de passagem de mensagens muito conhecido é o MPI (Message- 
Passing Interface). Ele é amplamente usado para computação científica. Para obter mais 
informações sobre ele, consulte, por exemplo, Gropp et al. (1994) e Snir et al. (1996). 


PROBLEMAS CLÁSSICOS DE COMUNICAÇÃO 
ENTRE PROCESSOS 


A literatura sobre sistemas operacionais está repleta de problemas da comunicação entre pro- 
cessos que foram amplamente discutidos, utilizando uma variedade de métodos de sincroni- 
zação. Nas seções a seguir, examinaremos dois dos problemas mais conhecidos. 


O problema da janta dos filósofos 


Em 1965, Dijkstra propôs e resolveu um problema de sincronização que chamou de pro- 
blema da janta dos filósofos. Desde essa época, todo mundo que inventava outra primitiva 
de sincronização sentiu-se obrigado a demonstrar como a nova primitiva era maravilhosa, 
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mostrando como resolvia elegantemente o problema da janta dos filósofos. O problema pode 
ser exposto de uma maneira simples, como segue. Cinco filósofos estão sentados ao redor de 
uma mesa circular. Cada filósofo tem um prato de espaguete. O espaguete é tão escorregadio 
que o filósofo precisa de dois garfos para comê-lo. Entre cada par de pratos há um garfo. A 
disposição da mesa está ilustrada na Figura 2-18. 


gi SI) 


li 
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Figura 2-18 Hora do jantar no Departamento de Filosofia. 


A vida de um filósofo consiste em alternar períodos de se alimentar e de pensar. (Esta é 
uma abstração, mesmo para filósofos, mas as demais atividades são irrelevantes aqui.) Quan- 
do um filósofo sente fome, ele tenta pegar os garfos da esquerda e da direita, um de cada vez, 
em qualquer ordem. Se conseguir pegar os dois garfos, ele come por algum tempo e, então, 
coloca os garfos na mesa e continua a pensar. A pergunta fundamental é: você consegue es- 
crever um programa para cada filósofo que faça o que deve fazer e nunca entre em impasse 
(deadlock)? (Foi mostrado que a exigência de dois garfos é um tanto artificial; talvez devês- 
semos trocar a comida italiana por comida chinesa, substituindo o espaguete por arroz e os 
garfos por pauzinhos.) 

A Figura 2-19 mostra a solução óbvia. A procedure take_fork espera até que o garfo 
especificado esteja disponível e, então, apodera-se dele. Infelizmente, a solução óbvia está 
errada. Suponha que os cinco filósofos peguem os garfos da esquerda simultaneamente. Ne- 
nhum será capaz de pegar os garfos da direita e haverá um impasse. 

Poderíamos modificar o programa de modo que, após pegar o garfo da esquerda, ele 
verificasse se o garfo da direita está disponível. Se não estiver, o filósofo coloca o garfo da 
esquerda na mesa, espera algum tempo e, então, repete o processo inteiro. Essa proposta 
também fracassa, embora por uma razão diferente. Com um pouquinho de azar, todos os 
filósofos poderiam iniciar o algoritmo simultaneamente, pegando os garfos da esquerda, 
vendo que os garfos da direita não estão disponíveis, colocando os garfos da esquerda na 
mesa, esperando, pegando outra vez os garfos da esquerda simultaneamente e assim por 
diante, eternamente. Uma situação como essa, na qual todos os programas continuam a exe- 
cutar indefinidamente, mas não conseguem fazer progresso algum, é chamada de inanição 
(starvation). (E chama-se inanição mesmo quando o problema não ocorre em um restaurante 
italiano ou chinês.) 
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tdefine N 5 /* número de filósofos */ 

void philosopher(int i) /* i: número do filósofo, de O a 4 */ 

{ 

while (TRUE) { 

think(); /* o filósofo está pensando */ 
take_fork(i); /* pega o garfo da esquerda */ 
take_fork((i+1) % N); /* pega o garfo da direita; % é o operador de módulo */ 
eat(); /* nham-nham, espaguete! */ 
put fork(i); /* coloca o garfo da esquerda de volta na mesa */ 
put fork((i+1) % N); /* coloca o garfo da direita de volta na mesa */ 


} 


Figura 2-19 Uma solução errada para o problema da janta dos filósofos. 


Agora você poderia pensar: “se os filósofos esperassem um tempo aleatório, em vez do 
mesmo tempo, após não conseguirem pegar o garfo da direita, a chance de que tudo continue 
em cadência, mesmo por uma hora, seria muito pequena”. Essa observação é válida e em prati- 
camente todos os aplicativos, tentar outra vez posteriormente não é problema. Por exemplo, em 
uma rede local usando Ethernet, um computador só envia dados quando percebe que nenhum 
outro computador está enviando. Entretanto, devido aos atrasos na transmissão em um cabo, 
dois computadores podem enviar dados simultaneamente sobrepondo-os — nesse caso, diz-se 
que houve uma colisão. Quando é detectada uma colisão, cada computador espera por um 
tempo aleatório e tenta novamente; na prática, essa solução funciona bem. Contudo, em alguns 
aplicativos, é necessário uma solução que funcione sempre e que não falhe devido a uma série 
improvável de números aleatórios. Pense no controle de segurança de uma usina nuclear. 

Um aprimoramento na Figura 2-19, que não resultaria em impasse nem em inanição, 
é proteger as cinco instruções após a chamada de think com um semáforo binário. Antes de 
começar a pegar os garfos, um filósofo executaria uma operação down em mutex. Depois de 
devolver os garfos, ele executaria uma operação up em mutex. Do ponto de vista teórico, essa 
solução é adequada. Do ponto de vista prático, ela apresenta uma falha em termos de de- 
sempenho: apenas um filósofo pode se alimentar de cada vez. Com cinco garfos disponíveis, 
deveríamos ser capazes de permitir que dois filósofos comessem ao mesmo tempo. 

A solução mostrada na Figura 2-20 não apresenta impasse e permite o máximo parale- 
lismo para um número arbitrário de filósofos. Ela utiliza um array, state, para controlar se um 
filósofo está comendo, pensando ou se está com fome (tentando pegar garfos). Um filósofo 
só pode passar para o estado “comendo” se nenhum vizinho estiver comendo. Os vizinhos do 
filósofo i são definidos pelas macros LEFT e RIGHT. Em outras palavras, se i é 2, LEFT é 1 
e RIGHT é3. 

O programa utiliza um array de semáforos, um por filósofo, de modo que os filósofos 
que estão com fome podem ser bloqueados, caso os garfos necessários estejam ocupados. 
Note que cada processo executa a função philosopher como seu código principal, mas take_ 
forks, put forks e test, são funções comuns e não processos separados. 


O problema dos leitores e escritores 


O problema da janta dos filósofos é útil para modelar processos que estão competindo pelo 
acesso exclusivo a um número limitado de recursos, como dispositivos de E/S. Outro proble- 
ma famoso é o dos leitores e escritores, que modela o acesso a um banco de dados (Courtois 
et al., 1971). Imagine, por exemplo, um sistema de reservas de uma companhia aérea, com 
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tdefine N 5 

tdefine LEFT (i+N—1)%N 
#define RIGHT (i+1)%N 
#define THINKING O 

#define HUNGRY 1 

#define EATING 2 

typedef int semaphore; 

int state[N]; 

semaphore mutex = 1; 
semaphore s[N]; 


void philosopher(int i) 
( 
while (TRUE) ( 
think(); 
take forks(i); 
eat(); 
put forks(i); 


) 


void take forks(int i) 

{ 
down(&mutex); 
state[i] = HUNGRY; 
test(i); 
up(&mutex); 
down(&sfi]); 

) 


void put forks(i) 


/* número de filósofos */ 

/* número do vizinho à esquerda de i */ 

/* número do vizinho à direita de i */ 

/* o filósofo está pesando */ 

/* o filósofo está tentando pegar garfos */ 

/* o filósofo está comendo */ 

/* os semáforos são um tipo especial de int */ 
/* array para controlar o estado de todos */ 

/* exclusão mútua para regiões críticas */ 

/* um semáforo por filósofo */ 


/* i: número do filósofo, de 0 a N - 1 */ 


/* repete eternamente */ 

/* o filósofo está pensando */ 

/* pega dois garfos ou bloqueia */ 

/* nham-nham, espaguete */ 

/* coloca os dois garfos de volta na mesa */ 


/* i: número do filósofo, de O a N - 1 */ 


/* entra na região crítica */ 

/* registra o fato de que o filósofo i está com fome */ 
/* tenta pegar 2 garfos */ 

/* sai da região crítica */ 

/* bloqueia se os garfos não foram pegos */ 


/* i: número do filósofo, de O a N - 1 */ 


/* entra na região crítica */ 

/* o filósofo acabou de comer */ 

/* verifica se o vizinho da esquerda pode comer agora */ 
/* verifica se o vizinho da direita pode comer agora */ 

/* sai da região crítica */ 


/* i: número do filósofo, de O a N - 1 */ 


if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { 


{ 
down(&mutex); 
state[i] = THINKING; 
test(LEFT); 
test(RIGHT); 
up(&mutex); 
) 
void test(i) 
{ 
state[i] = EATING; 
up(&s[i); 
) 
) 


Figura 2-20 Uma solução para o problema da janta dos filósofos. 


muitos processos concorrentes querendo ler e escrever. É aceitável ter vários processos len- 
do o banco de dados ao mesmo tempo, mas se um processo estiver atualizando (escrevendo) 
o banco de dados, nenhum outro processo poderá ter acesso ao banco, nem mesmo um lei- 
tor. A pergunta é: como você programa os leitores e os escritores? Uma solução aparece na 
Figura 2-21. 
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typedef int semaphore; 
semaphore mutex = 1; 
semaphore db = 1; 
intrc=0; 


void reader(void) 
{ 
while (TRUE) { 

down(&mutex); 
rc=rc+ 1; 
if (rc == 1) down(&db); 
up(&mutex); 
read_data_base(); 
down(&mutex); 
rc=rc-1; 
if (rc == 0) up(&db); 
up(&mutex); 
use_data_read(); 


void writer(void) 


{ 
while (TRUE) { 
think_up_data(); 
down(&db); 
write_data_base(); 
up(&db); 
} 
} 
Figura 2-21 


/* use sua imaginação */ 

/* controla o acesso a 'rc' */ 

/* controla o acesso ao banco de dados */ 

/* número de processos lendo ou querendo ler */ 


/* repete indefinidamente */ 

/* obtém acesso exclusivo a ‘rc’ */ 

/* um leitor a mais agora */ 

/* se este for o primeiro leitor ... */ 

/* libera o acesso exclusivo para ‘rc’ */ 
/* acessa os dados */ 

/* obtém acesso exclusivo a ‘rc’ */ 

/* um leitor a menos agora */ 

/* se este for o último leitor ... */ 

/* libera o acesso exclusivo para ‘rc’ */ 
/* região não-crítica */ 


/* repete indefinidamente */ 
/* região não-crítica */ 

/* obtém acesso exclusivo */ 
/* atualiza os dados */ 

/* libera o acesso exclusivo */ 


Uma solução para o problema dos leitores e escritores. 


Nesta solução, o primeiro leitor a obter acesso ao banco de dados executa uma operação 
down no semáforo db. Os leitores subsegiientes precisam apenas incrementar um contador, 
rc. À medida que os leitores saem, eles decrementam o contador e o último deles executa uma 
operação up no semáforo, permitindo a entrada de um escritor bloqueado, caso haja um. 

A solução apresentada aqui contém, implicitamente, uma decisão sutil que merece co- 
mentário. Suponha que, enquanto um leitor está usando o banco de dados, outro leitor também 
o utilize. Como ter dois leitores ao mesmo tempo não é problema, o segundo leitor é admitido. 
Um terceiro leitor e os leitores subsegiientes também podem ser admitidos, caso apareçam. 

Agora, suponha que apareça um escritor. O escritor não pode ser admitido no banco de 
dados, pois os escritores devem ter acesso exclusivo, de modo que ele é bloqueado. Poste- 
riormente, aparecem outros leitores. Contanto que pelo menos um leitor ainda esteja ativo, 
leitores subsegiientes são admitidos. Como consegiiência dessa estratégia, enquanto houver 
um estoque constante de leitores, todos eles entrarão assim que chegarem. O escritor será 
mantido bloqueado até que nenhum leitor esteja presente. Se um novo leitor chegar, digamos, 
a cada 2 segundos, e cada leitor levar 5 segundos para fazer seu trabalho, o escritor nunca 
executará. 

Para evitar essa situação, o programa pode ser escrito de maneira ligeiramente diferen- 
te: quando um leitor chega e um escritor está esperando, o leitor é bloqueado atrás do escritor, 
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2.4 
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em vez de ser admitido imediatamente. Dessa maneira, um escritor precisa esperar o término 
dos leitores que estavam ativos quando ele chegou, mas não precisa esperar os leitores que 
apareceram depois dele. A desvantagem dessa solução é que ela gera menos concorrência e, 
portanto, tem desempenho inferior. Courtois et al. apresentam uma solução que dá prioridade 
aos escritores. Para ver os detalhes, sugerimos a leitura desse artigo. 


ESCALONAMENTO 


Nos exemplos das seções anteriores, com frequência tivemos situações em que dois ou mais 
processos (por exemplo, produtor e consumidor) eram logicamente executáveis. Quando um 
computador tem suporte a multiprogramação, frequentemente ele tem vários processos com- 
petindo pela CPU ao mesmo tempo. Quando mais de um processo está no estado pronto e 
existe apenas uma CPU disponível, o sistema operacional deve decidir qual deles vai executar 
primeiro. A parte do sistema operacional que faz essa escolha é chamada de escalonador; o 
algoritmo que ele utiliza é chamado de algoritmo de escalonamento. 

Muitos problemas de escalonamento se aplicam tanto aos processos como as threads. 
Inicialmente, focalizaremos o escalonamento de processos, mas posteriormente examinare- 
mos rapidamente alguns problemas específicos ao escalonamento de threads. 


Introdução ao escalonamento 


Na época dos sistemas de lote, com entrada na forma de uma fita magnética, o algoritmo de 
escalonamento era simples: apenas executar o próximo job da fita. Nos sistemas com compar- 
tilhamento de tempo, o algoritmo de escalonamento se tornou mais complexo, pois geralmen- 
te havia vários usuários esperando o serviço. Também pode haver um ou mais fluxos de lote 
(por exemplo, em uma companhia de seguros, para processar pedidos). Em um computador 
pessoal, você poderia pensar que haveria apenas um processo ativo. Afinal, é improvável que 
um usuário digitando um documento em um processador de textos esteja simultaneamente 
compilando um programa em segundo plano. Entretanto, fregientemente existem tarefas de 
segundo plano, como daemons de correio eletrônico enviando ou recebendo e-mail. Você 
também poderia pensar que os computadores ficaram tão mais rápidos com o passar dos anos, 
que a CPU raramente teria falta de recursos. Contudo, os aplicativos novos tendem a exigir 
mais recursos. Exemplo disso é o processamento digital de fotografias e a exibição de vídeo 
em tempo real. 


Comportamento dos processos 


Praticamente todos os processos alternam rajadas de computação com requisições de E/S 
(disco), como mostra a Figura 2-22. Normalmente, a CPU executa por algum tempo sem 
parar e, depois, é feita uma chamada de sistema para ler ou escrever em um arquivo. Quando 
a chamada de sistema termina, a CPU computa novamente, até precisar de mais dados ou 
ter de escrever mais dados e assim por diante. Note que algumas atividades de E/S contam 
como computação. Por exemplo, quando a CPU copia dados de uma memória de vídeo para 
atualizar a tela, ela está computando e não fazendo E/S, pois a CPU está sendo usada. Nesse 
sentido, a E/S se dá quando um processo entra no estado bloqueado esperando que um dispo- 
sitivo externo conclua seu trabalho. 

O importante a notar na Figura 2-22 é que alguns processos, como o que aparece na 
Figura 2-22(a), passam a maior parte de seu tempo computando, enquanto outros, como o 
que aparece na Figura 2-22(b), passam a maior parte de seu tempo esperando por E/S. Os pri- 
meiros são chamados de processos limitados por processamento (CPU-bound); os últimos 
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são chamados de processos limitados por E/S (1/0-bound). Os processos limitados por pro- 
cessamento normalmente têm longas rajadas de uso de CPU e raramente esperam pela E/S, 
enquanto os processos limitados por E/S têm curtas rajadas de uso de CPU curtas e esperas 
freqüentes por E/S. Note que o principal fator é o comprimento da rajada de uso de CPU e 
não o comprimento da rajada de E/S. Os processos limitados por E/S são classificados como 
tal não por terem requisições de E/S particularmente longas, mas sim por não executarem 
muita computação entre elas. O tempo para ler um bloco de disco é sempre o mesmo, inde- 
pendente de se gastar muito ou pouco tempo para processar os dados lidos. 


(a) 


a 


Rajada longa de CPU 


Esperando por E/S 
Rajada curta de CPU 


M 


Tempo 


(b) 


Figura 2-22 As rajadas de utilização de CPU alternam com períodos de espera por F/S. (a) 
Um processo vinculado à CPU. (b) Um processo limitado por F/S. 


É interessante notar que, à medida que as CPUs se tornam mais rápidas, os processos 
tendem a ficar limitados por E/S. Esse efeito ocorre porque as CPUs estão evoluindo muito 
mais rapidamente do que os discos. Como consegiiência, o escalonamento de processos limita- 
dos por E/S provavelmente se tornará um assunto bem mais importante no futuro. A idéia bási- 
ca aqui é que, se um processo limitado por E/S quiser ser executado, deverá ter uma chance de 
fazê-lo rapidamente, para que possa emitir sua requisição ao disco e mantê-lo ocupado. 


Quando fazer o escalonamento 
Existe uma variedade de situações nas quais o escalonamento pode ocorrer. Primeiramente, o 
escalonamento é absolutamente exigido em duas ocasiões: 
1. Quando um processo termina. 
2. Quando um processo é bloqueado em uma operação de E/S ou em um semáforo. 
Em cada um desses casos, o processo que estava em execução se torna não apto a conti- 
nuar, de modo que outro processo deva ser escolhido para executar em seguida. 
Existem três outras ocasiões em que o escalonamento é normalmente feito, embora, 
logicamente falando, não seja absolutamente necessário nesses momentos: 
1. Quando um novo processo é criado. 
2. Quando ocorre uma interrupção de E/S. 
3. Quando ocorre uma interrupção de relógio. 


No caso de um novo processo, faz sentido reavaliar as prioridades nesse momento. Em 
alguns casos, o processo pai pode solicitar uma prioridade diferente para o processo filho. 
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No caso de uma interrupção de E/S, isso normalmente significa que um dispositivo de 
E/S acabou de concluir seu trabalho. Assim, algum processo que estava bloqueado, esperando 
pela E/S, poderá agora estar pronto (ou apto) para executar. 

No caso de uma interrupção de relógio, essa é uma oportunidade para decidir se o pro- 
cesso que está correntemente em execução já está executando por um tempo demasiado. Os 
algoritmos de escalonamento podem ser divididos em duas categorias, com relação ao modo 
como tratam das interrupções de relógio. Um algoritmo de escalonamento não-preemptivo 
seleciona um processo para executar e, em seguida, permite que ele seja executado até ser 
bloqueado (ou no caso de uma E/S ou na espera por outro processo) ou até que libere a CPU 
voluntariamente. Em contraste, um algoritmo de escalonamento preemptivo seleciona um 
processo e permite que ele seja executado por algum tempo fixo máximo. Se o processo 
ainda estiver em execução no final do intervalo de tempo, ele será suspenso e o escalonador 
selecionará outro processo para executar (se houver um disponível). O escalonamento pre- 
emptivo exige a ocorrência de uma interrupção de relógio no final do intervalo de tempo, para 
devolver o controle da CPU para o escalonador. Se não houver nenhum relógio disponível, a 
escalonamento não-preemptivo será a única opção. 


Categorias de algoritmos de escalonamento 


Evidentemente, em diferentes ambientes, são necessários diferentes algoritmos de escalo- 
namento. Essa situação surge porque as diferentes áreas de aplicação (e diferentes tipos de 
sistemas operacionais) têm objetivos diversos. Em outras palavras, o que o escalonador deve 
otimizar não é a mesma coisa em todos os sistemas. É importante distinguir três ambientes: 


1. Lote 
2. Interativo 


3. Tempo real 


Nos sistemas de lote, não há usuários esperando impacientemente uma resposta rápida 
em seus terminais. Consegiientemente, com fregiiência são aceitáveis algoritmos não-pre- 
emptivos ou algoritmos preemptivos com longos períodos de tempo para cada processo. Essa 
estratégia reduz as trocas de processo e, assim, melhora o desempenho. 

Em um ambiente com usuários interativos, a preempção é fundamental para impedir 
que um processo aproprie-se de todo o tempo de CPU e negue serviço para os outros. Mes- 
mo que nenhum processo seja executado para sempre intencionalmente devido a um erro 
de programa, um único processo poderia barrar os outros indefinidamente. A preempção é 
necessária para evitar esse comportamento. 

Nos sistemas com restrições de tempo real, às vezes, a preempção é, estranhamente, 
desnecessária, pois os processos sabem que não podem ser executados por longos períodos de 
tempo e normalmente fazem seu trabalho e são rapidamente bloqueados. A diferença com os 
sistemas interativos é que os sistemas de tempo real executam apenas os programas necessá- 
rios a uma aplicação em particular. Já os sistemas interativos são de propósito geral e podem 
executar qualquer tipo de programa, inclusive os que são mal-intencionados. 


Objetivos dos algoritmos de escalonamento 


Para projetar um algoritmo de escalonamento, é necessário ter alguma idéia do que um bom 
algoritmo deve fazer. Alguns objetivos dependem do ambiente (lote, interativo ou tempo 
real), mas também existem outros que são desejáveis para todos os casos. Alguns objetivos 
estão listados na Figura 2-23. A seguir, os discutiremos cada um deles. 
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Todos os sistemas 
Imparcialidade — dar a cada processo o mesmo tempo de uso de CPU 
Imposição da política — garantir que a política declarada é executada 
Balanceamento de carga — manter todas as partes do sistema ocupadas 


Sistemas de lote 
Taxa de saída — maximizar o número de jobs por hora 
Tempo de retorno — minimizar o tempo entre envio e término 
Utilização da CPU — manter a CPU ocupada o máximo de tempo possível 


Sistemas interativos 
Tempo de resposta — atender rapidamente as requisições 
Proporcionalidade —satisfazer às expectativas dos usuários 


Sistemas de tempo real 
Cumprir os prazos finais — evitar a perda de dados 
Previsibilidade — evitar degradação da qualidade em sistemas multimídia 


Figura 2-23 Alguns objetivos dos algoritmos de escalonamento sob diferentes circuns- 
tâncias. 


Sob todas as circunstâncias, a imparcialidade é importante. Processos comparáveis de- 
vem receber serviço comparável. Dar para um processo muito mais tempo de CPU do que 
para outro equivalente não é justo. Naturalmente, diferentes categorias de processos podem 
ser tratadas de formas diferentes. Pense no controle de segurança e no processamento da fo- 
lha de pagamento do centro de computação de um reator nuclear. 

Um tanto relacionada com a imparcialidade é a imposição das políticas do sistema. Se 
a política local diz que os processos de controle de segurança devem ser executados quando 
quiserem, mesmo que isso signifique que a folha de pagamento seja atrasada em 30 segundos, 
o escalonador precisa garantir que essa política seja imposta. 

Outro objetivo geral é manter todas as partes do sistema ocupadas, quando possível. 
Se a CPU e todos os dispositivos de E/S puderem ser mantidos ocupados o tempo todo, será 
feito, por segundo, mais trabalho do que se alguns dos componentes estiverem ociosos. Em 
um sistema de lote, por exemplo, o escalonador tem controle sobre quais tarefas são levadas à 
memória para execução. Ter alguns processos vinculados à CPU e alguns processos limitados 
por E/S em memória é uma idéia melhor do que primeiro carregar e executar todas as tarefas 
vinculadas à CPU e, depois, quando elas tiverem terminado, carregar e executar todas as ta- 
refas vinculadas à E/S. Se esta última estratégia for usada, quando os processos vinculados à 
CPU estiverem em execução, eles lutarão pela CPU e o disco estará ocioso. Posteriormente, 
quando as tarefas vinculadas à E/S entrarem em ação, elas disputarão o disco e a CPU estará 
ociosa. É melhor manter o sistema todo em funcionamento simultaneamente, por meio de 
uma mistura cuidadosa de processos. 

Os gerentes dos centros de computação corporativos que executam muitas tarefas de 
lote (por exemplo, processamento de pedidos de companhias de seguro), normalmente exa- 
minam três métricas para avaliarem o desempenho de seus sistemas: taxa de saída (throu- 
ghput), tempo de retorno (turnaround) e utilização da CPU. A taxa de saída é o número de 
jobs por segundo que o sistema conclui. Considerando tudo os fatores, concluir 50 jobs por 
segundo é melhor do que concluir 40 jobs por segundo. Tempo de retorno é o tempo médio 
desde o momento em que um job do lote é submetido até o momento em que ele é concluído. 
Ele mede o tempo que o usuário médio precisa esperar pela saída. Aqui, a regra é: quanto 
menor, melhor. 
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Um algoritmo de escalonamento que maximiza a taxa de saída pode não necessaria- 
mente minimizar o tempo de retorno. Por exemplo, dada uma mistura de jobs curtos e longos, 
um escalonador que sempre executasse os jobs curtos e nunca os jobs longos poderia obter 
uma taxa de saída excelente (muitos jobs curtos por segundo), mas à custa de um tempo de 
retorno terrível para os jobs longos. Se jobs curtos continuassem chegando constantemente, 
os jobs longos poderiam nunca ser executados, tornando o tempo de retorno médio infinito, 
embora obtivesse uma taxa de saída alta. 

A utilização da CPU também é um problema nos sistemas de lote porque, nos compu- 
tadores de grande porte, onde os sistemas de lote são executados, a CPU ainda tem um custo 
alto. Assim, os gerentes dos centros de computação se sentem culpados quando ela não está 
executando o tempo todo. Na verdade, contudo, essa não é uma boa métrica. O que realmente 
importa é quantos jobs por segundo saem do sistema (taxa de saída) e quanto tempo demora 
para retornar um job (tempo de retorno). Usar a utilização da CPU como métrica é como 
classificar carros tendo por base o giro do motor por segundo. 

Para sistemas interativos, especialmente sistemas de compartilhamento de tempo e ser- 
vidores, diferentes objetivos se aplicam. O mais importante é minimizar o tempo de respos- 
ta, que é o tempo entre a execução de um comando e o recebimento de seu resultado. Em um 
computador pessoal, onde está sendo executado um processo de segundo plano (por exemplo, 
lendo e armazenando e-mail na rede), o pedido de um usuário para iniciar um programa ou 
abrir um arquivo deve ter precedência sobre o trabalho de segundo plano. O fato de ter todos 
os pedidos interativos atendidos primeiro será percebido como um bom serviço. 

Um problema relacionado é o que poderia ser chamado de proporcionalidade. Os 
usuários têm uma idéia básica (mas freqiientemente incorreta) do tempo que as coisas devem 
demorar. Quando um pedido que é percebido como complexo demora um longo tempo, os 
usuários aceitam isso, mas quando um pedido que é percebido como simples demora um 
longo tempo, os usuários ficam irritados. Por exemplo, se clicar em um ícone que ativa um 
provedor de Internet usando um modem analógico demorar 45 segundos para estabelecer a 
conexão, o usuário provavelmente aceitará isso como um fato normal. Por outro lado, se cli- 
car em um ícone para desfazer uma conexão demorar 45 segundos, o usuário provavelmente 
estará dizendo palavrões na marca dos 30 segundos e, decorridos 45 segundos, já estará espu- 
mando de raiva. Esse comportamento é devido à percepção comum do usuário de que fazer 
uma ligação telefônica e estabelecer uma conexão provavelmente demora muito mais do que 
apenas desligar. Em alguns casos (como neste), o escalonador não pode fazer nada a respeito 
do tempo de resposta, mas em outros casos, ele pode, especialmente quando o atraso é devido 
a uma escolha malfeita na ordem dos processos. 

Os sistemas de tempo real têm propriedades diferentes dos sistemas interativos e, as- 
sim, diferentes objetivos de escalonamento. Eles são caracterizados por terem prazos finais 
que devem ou pelo menos deveriam ser cumpridos. Por exemplo, se um computador está 
controlando um dispositivo que produz dados a uma velocidade regular, o fato de deixar de 
executar o processo de coleta de dados pontualmente pode resultar na sua perda. Assim, a 
principal necessidade em um sistema de tempo real é cumprir todos os prazos finais (ou a 
maioria deles). 

Em alguns sistemas de tempo real, especialmente aqueles que envolvem multimídia, a 
previsibilidade é importante. Perder um prazo final ocasional não é fatal, mas se o processo 
de áudio for executado muito irregularmente, a qualidade do som se deteriorará rapidamente. 
O vídeo também é um problema, mas os ouvidos são muito mais sensíveis à flutuação de fase 
do que os olhos. Para evitar esse problema, a escalonamento dos processos deve ser altamente 
previsível e regular. 
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2.4.2 Escalonamento em sistemas de lote 


Agora é hora de examinarmos os problemas gerais de algoritmos de escalonamento especí- 
ficos. Nesta seção, veremos os algoritmos usados nos sistemas de lote. Nas seguintes, exa- 
minaremos os sistemas interativos e de tempo real. Vale notar que alguns algoritmos são 
usados tanto em sistemas de lote como em sistemas interativos. Vamos estudar estes últimos 
posteriormente. Aqui, focalizaremos os algoritmos que são convenientes apenas nos sistemas 
de lote. 


O primeiro a chegar é o primeiro a ser atendido 


Provavelmente, o mais simples de todos os algoritmos de escalonamento é o não-preemptivo 
primeiro a chegar é o primeiro a ser atendido” (First-come First-served FCFS). Nesse 
algoritmo, os processos recebem tempo de CPU na ordem em que solicitam. Basicamente, 
existe uma única fila de processos prontos (aptos a executar). Quando, de manhã, o primeiro 
job entra no sistema, ele é iniciado imediatamente e pode ser executado durante o tempo que 
quiser. Quando outros jobs chegam, eles são colocados no final da fila. Quando o proces- 
so que está em execução é bloqueado, o primeiro processo da fila é executado em seguida. 
Quando um processo bloqueado se torna pronto, assim como um job recém-chegado, é colo- 
cado no final da fila. 

A maior vantagem desse algoritmo é que ele é fácil de ser entendido e igualmente fácil 
de programar. Ele também é imparcial, da mesma forma que é justo vender entradas para 
jogos ou concertos muito concorridos para as pessoas que estejam dispostas a ficar na fila às 
2 da manhã. Com esse algoritmo, uma lista encadeada simples mantém todos os processos 
prontos. Selecionar um processo para executar exige apenas remover um do início da fila. 
Adicionar uma nova tarefa ou um processo que acaba de ser desbloqueado exige apenas inse- 
ri-lo no final da fila. O que poderia ser mais simples? 

Infelizmente, o algoritmo do primeiro a chegar é o primeiro a ser atendido também 
tem uma grande desvantagem. Suponha que exista um único processo limitado por proces- 
samento que seja executado por 1 segundo a cada vez e muitos processos limitados por E/S 
que utilizam pouco tempo da CPU, mas cada um tendo que realizar 1000 leituras de disco 
para terminar. O processo limitado por processamento é executado por 1 segundo e, em se- 
guida, lê um bloco de disco. Agora, todos os processos de E/S são executados e começam as 
leituras de disco. Quando o processo limitado por processamento recebe seu bloco de disco, 
é executado por mais 1 segundo, seguido de todos os processos limitados por E/S, em uma 
rápida sucessão. 

O resultado final é que cada processo limitado por E/S lê 1 bloco por segundo e demora 
1000 segundos para terminar. Se fosse usado um algoritmo de escalonamento que fizesse a 
preempção do processo limitado por processamento a cada 10 ms, os processos limitados por 
E/S terminariam em 10 segundos, em vez de 1000 segundos, e sem diminuir muito a veloci- 
dade do processo limitado por processamento. 


Tarefa mais curta primeiro 


Examinemos agora outro algoritmo não-preemptivo para sistemas de lote que presume que 
os tempos de execução são conhecidos antecipadamente. Em uma companhia de seguros, por 
exemplo, as pessoas podem prever precisamente quanto tempo levará para executar um lote 
de 1.000 pedidos, pois um trabalho semelhante é feito todos os dias. Quando várias tarefas 


* N. de R.T.: Esse algoritmo também é denominado de primeiro a chegar, primeiro a sair (First-In, First-Out ou, simplesmente, 


FIFO). 
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igualmente importantes estão na fila de entrada esperando para serem iniciadas, o escalona- 
dor seleciona a tarefa mais curta primeiro (Shortest Job First - SJF). Veja a Figura 2-24. 
Aqui, encontramos quatro jobs A, B, Ce D, com tempos de execução de 8, 4, 4 e 4 minutos, 
respectivamente. Executando-as nessa ordem, o tempo de retorno para A é de 8 minutos, para 
B é de 12 minutos, para C é de 16 minutos e para D é de 20 minutos, dando uma média de 14 
minutos. 


8 4 4 4 4 4 4 8 
(a) (b) 


Figura 2-24 Um exemplo de escalonamento com a tarefa mais curta primeiro. (a) Executan- 
do quatro jobs na ordem original. (b) Executando-as na ordem do job mais curto primeiro. 


Agora, consideremos a execução desses quatro jobs utilizando o algoritmo da tarefa 
mais curta primeiro, como mostrado na Figura 2-24(b). Os tempos de retorno agora são de 4, 
8, 12 e 20 minutos, para uma média de 11 minutos. O algoritmo da tarefa mais curta primeiro 
provavelmente é ótimo. Considere o caso de quatro jobs, com tempos de execução de a, b, c e 
d, respectivamente. O primeiro job acaba no tempo a, o segundo no tempo a + b e assim por 
diante. O tempo de retorno médio é (4a + 3b + 2c + d)/4. É claro que a contribui mais para 
a média do que os outros tempos; portanto, ele deve ser o job mais curto, com b vindo em 
seguida, depois c e, finalmente, d como a mais longo, pois ele afeta apenas seu próprio tempo 
de retorno. O mesmo argumento aplica-se igualmente bem a qualquer número de jobs. 

É interessante notar que o algoritmo da tarefa mais curta primeiro é ótimo apenas quan- 
do todos os jobs estão disponíveis simultaneamente. Como um contra-exemplo, considere 
cinco jobs, de A a E, com tempos de execução de 2, 4, 1, 1 e 1, respectivamente. Seus tempos 
de chegada são 0, 0, 3, 3 e 3. Inicialmente, apenas A ou B podem ser escolhidos, pois os ou- 
tros três jobs ainda não chegaram. Usando o algoritmo da tarefa mais curta primeiro, executa- 
remos os jobs na ordem A, B, C, D, E, para uma espera média de 4,6. Entretanto, executá-los 
na ordem B, C, D, E, A corresponde a uma espera média de 4,4. 


Menor tempo de execução restante 


Uma versão preemptiva do algoritmo da tarefa mais curta primeiro é o algoritmo do Me- 
nor tempo de execução restante (Shortest Remaining Time Next — SRT). Nesse algoritmo, 
o escalonador sempre escolhe o processo (ou job) cujo tempo de execução restante é o 
mais curto. Aqui, novamente, o tempo de execução precisa ser conhecido antecipadamente. 
Quando chega um novo job, seu tempo total é comparado com o tempo restante do processo 
corrente. Se o novo job precisar de menos tempo para terminar do que o processo corrente, 
este será suspenso e a novo job será iniciado. Este esquema permite que os novos jobs curtos 
recebam um bom serviço. 


Escalonamento em três níveis 


Sob certo aspecto, os sistemas de lote permitem escalonar processos em três níveis diferentes, 
conforme ilustrado na Figura 2-25. Quando os jobs chegam no sistema, eles são colocados 
inicialmente em uma fila de entrada armazenada em disco. O escalonador de admissão deci- 
de quais jobs ingressarão no sistema. Os outros são mantidos na fila de entrada até que sejam 
selecionados. Um algoritmo de controle de admissão típico poderia procurar uma mistura de 
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jobs limitados por processamento e jobs limitados por E/S. Como alternativa, os jobs curtos 
poderiam ser admitidos rapidamente, enquanto os jobs mais longos teriam de esperar. O es- 
calonador de admissão está livre para manter alguns jobs na fila de entrada e admitir jobs que 
cheguem depois, se optar por isso. 


Job 


chegando . 
Fila de 


entrada 


j Escalonador 
O | | Jojojojo! ==>» da memória ===> 


avi Disco 
Escalonador Memória 


de admissão principal 


Figura 2-25 Escalonamento em três níveis. 


Quando um job for admitido no sistema, um processo poderá ser criado para ele e 
poderá competir pela CPU. Entretanto, poderia ser que o número de processos fosse tão 
grande que não haveria espaço suficiente para todos eles em memória. Nesse caso, alguns 
dos processos teriam que ser postos no disco. O segundo nível de escalonamento é decidir 
quais processos devem ser mantidos em memória e quais devem ser mantidos no disco. Isso 
é chamado de escalonador da memória, pois ele determina quais processos são mantidos na 
memória e quais são mantidos no disco. 

Essa decisão precisa ser frequentemente revista para permitir que os processos que es- 
tão no disco recebam algum serviço. Entretanto, como trazer um processo do disco é dispen- 
dioso, essa revisão não deve acontecer mais do que uma vez por segundo, talvez com menos 
frequência ainda. Se o conteúdo da memória principal é trocado com muita frequência com 
o do disco, isso implica em um consumo de uma grande quantidade de largura de banda de 
disco, diminuindo a velocidade da E/S de arquivos. Essa alternância entre estar em memória 
principal e estar armazenado no disco é denominado de swapping. 

Para otimizar o desempenho do sistema como um todo, o escalonador da memória tal- 
vez queira decidir cuidadosamente quantos processos deseja ter na memória (o que é chama- 
do de grau de multiprogramação) e quais tipos de processos. Se ele tiver informações sobre 
quais processos são limitados por processamento e quais são limitados por E/S, poderá tentar 
manter uma mistura desses tipos de processo na memória. Como uma aproximação muito 
grosseira, se determinada classe de processos computa cerca de 20% do tempo, deixar cinco 
deles juntos é aproximadamente o número certo para manter a CPU ocupada. 

Para tomar suas decisões, o escalonador da memória revê periodicamente cada processo 
no disco para decidir se vai levá-lo para a memória ou não. Dentre os critérios que ele pode 
usar para tomar sua decisão estão os seguintes: 


1. Quanto tempo passou desde que o processo sofreu swap (entrou ou saiu)? 


2. Quanto tempo de CPU o processo recebeu recentemente? 
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3. Qual é o tamanho do processo? (Os pequenos não atrapalham.) 


4. Qual é a importância do processo? 


O terceiro nível de escalonamento é a seleção de um dos processos prontos, armazena- 
dos na memória principal, para ser executado em seguida. Fregiientemente, ele é chamado de 
escalonador da CPU e é o que as pessoas normalmente querem dizer quando falam sobre 
“escalonador”. Qualquer algoritmo pode ser usado aqui, tanto preemptivo como não-preemp- 
tivo. Eles incluem aqueles descritos anteriormente, assim como vários algoritmos que serão 
descritos na próxima seção. 


Escalonamento em sistemas interativos 


Veremos agora alguns algoritmos que podem ser usados em sistemas interativos. Todos eles 
também podem ser usados como escalonador da CPU em sistemas de lote. Embora a escalo- 
namento de três níveis não seja possível aqui, o escalonamento de dois níveis (escalonador da 
memória e escalonador da CPU) é comum. A seguir, focalizaremos o escalonador da CPU e 
alguns algoritmos de escalonamento mais empregados. 


Escalonamento round-robin 


Vamos ver agora alguns algoritmos de escalonamento específicos. Um dos algoritmos mais 
antigos, mais simples e mais amplamente utilizados é feito um rodízio entre os processos 
(escalonamento round-robin — RR). A cada processo é atribuído um intervalo de tempo, cha- 
mado de quantum, durante o qual ele pode ser executado. Se o processo estiver em execução 
no fim do quantum, é feita a preempção da CPU e esta é alocada a outro processo. É claro 
que, se o processo tiver sido bloqueado, ou terminado, antes do quantum ter expirado, a troca 
da CPU será feita neste momento. O round-robin é fácil de implementar. Tudo que o escalo- 
nador precisa fazer é manter uma lista de processos executáveis, como mostrado na Figura 
2-26(a). Quando o processo consome seu quantum, ele é colocado no fim da lista, como se 
vê na Figura 2-26(b) 


Processo Próximo Processo 
corrente processo corrente 


(a) (b) 


Figura 2-26 Escalonamento round-robin. (a) A lista de processos executáveis. (b) A lista de 
processos executáveis após B consumir seu quantum. 


O único problema interessante relacionado ao round-robin é a duração do quantum. 
Trocar de um processo para outro exige certa quantidade de tempo para fazer a administração 
— salvar e carregar registradores e mapas de memória, atualizar várias tabelas e listas, esvaziar 
e recarregar a cache de memória etc. Suponha que esse chaveamento de processo ou chave- 
amento de contexto, como às vezes é chamado, demore 1 ms, incluindo a troca de mapas de 
memória, esvaziar e recarregar a cache etc. Suponha também que o quantum seja configurado 
como 4 ms. Com esses parâmetros, depois de fazer 4 ms de trabalho útil, a CPU terá de gastar 
1 ms na troca (chaveamento) de processos. 20% do tempo da CPU serão desperdiçados em 
sobrecarga administrativa. Claramente, isso é demais. 
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Para melhorar a eficiência da CPU, poderíamos configurar o quantum como, digamos, 
100 ms. Agora, o tempo desperdiçado é de apenas 1%. Mas considere o que acontece em 
um sistema de compartilhamento de tempo, se dez usuários interativos pressionarem a tecla 
enter mais ou menos ao mesmo tempo. Dez processos serão colocados na lista de processos 
prontos. Se a CPU estiver ociosa, o primeiro processo começará imediatamente, o segundo 
poderá começar somente 100 ms depois e assim por diante. O infeliz último da fila talvez 
tenha de esperar 1 segundo antes de ter uma chance, supondo que todos os outros utilizem 
seus quanta inteiros. A maioria dos usuários achará lenta uma resposta de 1 s para um co- 
mando curto. 

Outro fator é que, se o quantum for configurado com um valor maior do que a rajada 
média de CPU, a preempção raramente acontecerá. Em vez disso, a maioria dos processos 
executará uma operação de bloqueio, antes que o quantum termine, causando a troca de pro- 
cesso. Eliminar a preempção melhora o desempenho, pois as trocas de processo só ocorrerão 
quando elas forem logicamente necessárias; isto é, quando um processo for bloqueado e não 
puder continuar porque está logicamente esperando por algo. 

A conclusão pode ser formulada como segue: configurar o quantum curto demais causa 
muita troca de processo e reduz a eficiência da CPU, mas configurá-lo longo demais pode 
causar um tempo de resposta ruim para pedidos interativos curtos. Um quantum em torno de 
20-50 ms frequentemente é um compromisso razoável. 


Escalonamento por prioridade 


O escalonamento round-robin faz a suposição implícita de que todos os processos são igual- 
mente importantes. Com freqiiência, as pessoas que possuem e operam computadores multiu- 
suários têm idéias diferentes sobre esse assunto. Em uma universidade, a ordem da prioridade 
pode ser os diretores primeiro, depois os professores, secretários, inspetores e, finalmente, 
os alunos. A necessidade de levar em conta fatores externos conduz ao escalonamento por 
prioridade. A idéia básica é simples: cada processo recebe uma prioridade e o processo pron- 
to, com a prioridade mais alta, tem permissão para executar. 

Mesmo em um PC com um único proprietário, pode haver múltiplos processos, alguns 
mais importantes do que outros. Por exemplo, um processo daemon que envia uma mensa- 
gem de correio eletrônico em segundo plano deve receber uma prioridade mais baixa do que 
a de um processo que exibe um filme na tela em tempo real. 

Para impedir que os processos de alta prioridade sejam executados indefinidamente, 
o escalonador pode diminuir a prioridade do processo correntemente em execução em cada 
tique de relógio (isto é, a cada interrupção de relógio). Se essa ação fizer com que sua prio- 
ridade caia abaixo da do próximo processo com maior prioridade, ocorrerá um chaveamento 
de processo. Como alternativa, cada processo pode receber um quantum de tempo máximo 
em que ele pode ser executado. Quando esse quantum esgota, é dada a chance de executar ao 
próximo processo com maior prioridade. 

As prioridades podem ser atribuídas aos processos estática ou dinamicamente. No com- 
putador de um ambiente militar, os processos iniciados pelos generais poderiam começar 
com prioridade 100, os processos iniciados pelos coronéis, com 90, pelos majores, 80, pe- 
los capitães, 70, pelos tenentes, 60 e assim por diante. Como alternativa, em um centro de 
computação comercial, as tarefas de alta prioridade poderiam custar 100 dólares por hora, 
os de prioridade média, 75 dólares por hora, e os de baixa prioridade, 50 dólares por hora. 
O sistema UNIX tem um comando, nice, que permite ao usuário reduzir voluntariamente a 
prioridade de seu processo, para ser gentil com os outros usuários. Ninguém o utiliza. 

As prioridades também podem ser atribuídas dinamicamente pelo sistema, para atender 
certos objetivos. Por exemplo, alguns processos são altamente limitados por E/S e gastam a 
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maior parte do seu tempo esperando a E/S terminar. Quando um processo assim quer a CPU, 
deve recebê-la imediatamente para permitir que ele inicie sua próxima requisição de E/S, a 
qual pode então prosseguir em paralelo com outro processo que realmente faz computação. 
Fazer com que o processo limitado por E/S espere um longo tempo pela CPU significará 
apenas que ele ocupará a memória por um tempo desnecessariamente longo. Um algoritmo 
simples para oferecer bom serviço para processos limitados por E/S é configurar a priorida- 
de como 1/f, onde f é a fração do último quantum utilizado por um processo. Um processo 
que utilizasse apenas 1 ms de seu quantum de 50 ms receberia prioridade 50, enquanto um 
processo que executasse 25 ms antes de bloquear receberia prioridade 2 e um processo que 
utilizou o quantum inteiro receberia prioridade 1. 

Muitas vezes é conveniente agrupar processos em classes de prioridade e utilizar esca- 
lonamento por prioridade entre as classes, mas escalonamento round-robin dentro de cada 
classe. A Figura 2-27 mostra um sistema com quatro classes de prioridade. O algoritmo de es- 
calonamento é o seguinte: enquanto houver processos executáveis na classe de prioridade 4, 
executa cada um apenas por um quantum, no sistema round-robin, e nunca se incomoda com 
as classes de prioridade mais baixa. Se a classe de prioridade 4 estiver vazia, então executa 
os processos de classe 3 no sistema round-robin. Se as classes 4 e 3 estiverem vazias, então 
executa a classe 2 no sistema de round-robin e assim por diante. Se as prioridades não forem 
ajustadas ocasionalmente, as classes de prioridade mais baixa poderão sofrer inanição. 


Cabeça Processos executáveis 
da fila 


(Prioridade mais alta) 


Prioridade 1 (Prioridade mais baixa) 


Figura 2-27 Um algoritmo de escalonamento com quatro classes de prioridade. 


O MINIX 3 usa um sistema semelhante à Figura 2-27, embora existam 16 classes de 
prioridade na configuração padrão. No MINIX 3, os componentes do sistema operacional 
são executados como processos. O MINIX 3 coloca as tarefas (drivers de E/S) e servidores 
(gerenciador de memória, sistema de arquivos e rede) nas classes de prioridade mais alta. A 
prioridade inicial de cada tarefa ou serviço é definida no momento da compilação; a E/S de 
um dispositivo lento pode receber prioridade mais baixa do que a E/S de um dispositivo mais 
rápido ou mesmo de um servidor. Geralmente, os processos de usuário têm prioridade mais 
baixa do que os componentes de sistema, mas todas as prioridades podem mudar durante a 
execução. 


Escalonamento por múltiplas filas 


Um dos primeiros escalonadores por prioridade estava no CTSS (Corbató et al., 1962). O 
CTSS tinha o problema de que o chaveamento de processos era muito lento porque o 7094 
podia armazenar apenas um processo na memória. Cada troca significava enviar o processo 
corrente para o disco e ler um novo processo do disco. Os projetistas do CTSS rapidamente 
perceberam que era mais eficiente dar um quantum grande para processos limitados por pro- 
cessamento, de vez em quando, em vez de frequentemente dar pequenos quanta (para reduzir 
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as trocas). Por outro lado, dar a todos os processos um quantum grande poderia significar 
um péssimo tempo de resposta, como já observamos. A solução foi configurar classes de 
prioridade. Os processos de classe mais alta eram executados por um quantum. Os processos 
na classe de prioridade mais alta seguinte eram executados por dois quanta. Os processos na 
próxima classe eram executados por quatro quanta e assim por diante. Quando um processo 
utilizava todos os quanta permitidos, ele era movido uma classe para baixo. 

Como exemplo, considere um processo que precisasse computar continuamente por 
100 quanta. Inicialmente, ele receberia um quantum e, então, seria trocado. Da próxima vez, 
ele receberia dois quanta antes de ser trocado. Em sucessivas execuções, ele poderia receber 
4,8, 16, 32 e 64 quanta, embora tivesse utilizado apenas 37 dos 64 quanta finais para com- 
pletar seu trabalho. Apenas 7 trocas seriam necessárias (incluindo o carregamento inicial), 
em vez de 100, com um algoritmo round-robin puro. Além disso, à medida que o processo 
se baixasse cada vez mais nas filas de prioridade, ele seria executado cada vez com menos 
frequência, poupando a CPU para processos interativos curtos. 

A seguinte política foi adotada para impedir que um processo que ao ser iniciado pela 
primeira vez necessitasse ser executado durante um longo tempo, mas se tornasse interativo 
posteriormente, fosse eternamente penalizado. Quando a tecla enter era pressionada em um 
terminal, o processo pertencente a esse terminal era movido para a classe de prioridade mais 
alta, supondo-se que ele estava para tornar-se interativo. Um belo dia, um usuário com um 
processo intensamente vinculado à CPU descobriu que o simples fato de pressionar enter vá- 
rias vezes, aleatoriamente, melhorava seu tempo de resposta. Ele contou isso a todos os seus 
amigos. Moral da história: na prática, acertar é muito mais difícil do que na teoria. 

Muitos outros algoritmos foram usados para atribuir classes de prioridade aos proces- 
sos. Por exemplo, o influente sistema XDS 940 (Lampson, 1968), construído em Berkeley, 
tinha quatro classes de prioridade, chamadas terminal, E/S, quantum curto e quantum longo. 
Quando um processo que estava esperando uma entrada de terminal era finalmente desper- 
tado, ele entrava na classe de maior prioridade (terminal). Quando um processo que estava 
esperando um bloco de disco tornava-se pronto, ele entrava na segunda classe. Quando um 
processo ainda estava em execução quando seu quantum esgotava, ele era inicialmente colo- 
cado na terceira classe. Entretanto, se um processo esgotasse seu quantum muitas vezes se- 
guidas, sem bloquear para terminal ou para outra operação de E/S, ele era movido para o final 
da fila. Muitos outros sistemas utilizam algo semelhante para favorecer usuários e processos 
interativos em detrimento dos processos que estão em segundo plano. 


Processo mais curto em seguida 


Como o algoritmo da tarefa mais curta primeiro (SJF — Shortest Job First) sempre produz 
o menor tempo médio de resposta para sistemas de lote, seria interessante se ele também 
pudesse ser usado para processos interativos. Até certo ponto, ele pode ser usado. Os proces- 
sos interativos geralmente seguem o padrão de esperar comando, executar comando, esperar 
comando, executar comando e assim por diante. Se considerássemos a execução de cada co- 
mando como uma “tarefa” separada, poderíamos então minimizar o tempo de resposta total, 
executando o processo mais curto primeiro (Shortest Process Next — SPN). O único problema 
é descobrir qual dos processos correntemente executáveis é o mais curto. 

Uma estratégia é fazer estimativas com base no comportamento passado e executar 
o processo com o menor tempo de execução estimado. Suponha que o tempo estimado por 
comando para um terminal seja Tọ. Agora, suponha que sua próxima execução seja medida 
como T,. Poderíamos atualizar nossa estimativa usando uma soma ponderada desses dois 
números; isto é, aTy+ (1-a)T,. Pela escolha de a podemos fazer o processo de estimativa ig- 
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norar as execuções antigas rapidamente ou lembrar delas durante muito tempo. Com a = 1/2, 
obtemos sucessivas estimativas de 


To Tl2+T/2, Tf4+T/4+T/2, Tf8+TI8+4+T/4+T/ 


Após três novas execuções, o peso de T, na nova estimativa caiu para 1/8. 

Às vezes, a técnica de estimar o próximo valor em uma série usando a média ponderada 
do valor corrente medido e a estimativa anterior é chamada de envelhecimento. Ela é apli- 
cável a muitas situações onde deve ser feita uma previsão com base em valores anteriores. O 
envelhecimento é particularmente fácil de implementar quando a = 1/2. Basta somar o novo 
valor à estimativa corrente e dividir a soma por 2 (deslocando-o 1 bit para a direita). 


Escalonamento garantido 


Uma estratégia completamente diferente de escalonamento é fazer promessas realistas aos 
usuários sobre o desempenho e, então, cumpri-las. Uma promessa realista e fácil de cumprir: 
se houver n usuários conectados enquanto você estiver trabalhando, você receberá cerca de 
1/n do poder da CPU. De maneira semelhante, em um sistema monousuário com n processos 
em execução, todas as tarefas sendo iguais, cada uma deve receber 1/n dos ciclos da CPU. 

Para cumprir essa promessa, o sistema deve monitorar quanto da CPU cada processo 
recebeu desde a sua criação. Então, ele calcula quanto da CPU é atribuído a cada um; isto é, 
o tempo desde a criação dividido por n. Como a quantidade de tempo da CPU que cada pro- 
cesso realmente recebeu também é conhecida, é simples calcular a proporção entre o tempo 
real da CPU consumido e o tempo da CPU atribuído. Uma proporção de 0,5 significa que um 
processo só recebeu metade do que devia ter recebido e uma proporção de 2,0 significa que 
um processo recebeu o dobro do tempo que lhe foi atribuído. O algoritmo, então, é executar o 
processo com a proporção mais baixa até que sua proporção fique acima do seu concorrente 
mais próximo. 


Escalonamento por sorteio 


Embora fazer promessas aos usuários e cumpri-las seja uma boa idéia, é difícil implemen- 
tá-las. Entretanto, outro algoritmo pode ser utilizado para fornecer resultados previsíveis de 
maneira semelhante, com uma implementação muito mais simples. Ele é chamado de escalo- 
namento por sorteio (Waldspurger e Weihl, 1994). 

A idéia básica é dar aos processos “bilhetes de loteria” para os vários recursos do sis- 
tema, como o tempo de CPU. Quando uma decisão de escalonamento tiver de ser tomada, 
um “bilhete de loteria” é sorteado aleatoriamente e o processo que possui esse bilhete recebe 
o recurso. Quando aplicado ao escalonamento da CPU, o sistema pode realizar sorteios 50 
vezes por segundo, com cada vencedor recebendo como prêmio 20 ms do tempo da CPU. 

Parafraseando George Orwell, “todos os processos são iguais, mas alguns são mais 
iguais”. Os processos mais importantes podem receber bilhetes extras, para aumentar suas 
chances de ganhar. Se houver 100 bilhetes concorrendo e um processo tiver 20 deles, ele terá 
20% de chance de ganhar em cada sorteio. A longo prazo, ele receberá aproximadamente 
20% da CPU. Em contraste com um escalonador por prioridade, onde é muito difícil dizer o 
que uma prioridade de 40 significa realmente, aqui a regra é clara: um processo contendo uma 
fração f dos bilhetes receberá cerca de uma fração f do recurso em questão. 

O escalonamento por sorteio tem algumas propriedades interessantes. Por exemplo, se 
um novo processo aparece e recebe alguns bilhetes, no próximo sorteio ele terá uma chance 
de ganhar proporcional ao número de bilhetes que possui. Em outras palavras, o escalona- 
mento por sorteio é altamente sensível. 
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Processos cooperativos podem trocar bilhetes se quiserem. Por exemplo, quando um 
processo cliente envia uma mensagem para um processo servidor e, então, é bloqueado, ele 
pode dar todos os seus bilhetes para o servidor, para aumentar a chance de o servidor ser 
executado em seguida. Quando o servidor tiver terminado, ele devolverá os bilhetes para que 
o cliente possa ser executado novamente. Na verdade, na ausência de clientes, os servidores 
não precisam de nenhum bilhete. 

O escalonamento por sorteio pode ser usado para resolver problemas difíceis de lidar 
com outros métodos. Um exemplo é um servidor de vídeo onde vários processos estão en- 
viando sequências de vídeo para seus clientes, mas em diferentes velocidades de projeção. 
Suponha que os processos precisem de velocidades de 10, 20 e 25 quadros/s. Alocando para 
esses processos 10, 20 e 25 bilhetes, respectivamente, eles dividirão a CPU na proporção 
correta automaticamente; isto é, 10:20:25. 


Escalonamento com compartilhamento imparcial 


Até aqui, supomos que cada processo é programado para executar por conta própria, sem 
considerar quem é seu proprietário. Como resultado, se o usuário 1 inicia 9 processos e o 
usuário 2 inicia 1 processo, com os algoritmos round-robin ou de prioridades iguais, o usuá- 
rio 1 receberá 90% da CPU e o usuário 2 receberá apenas 10% dela. 

Para evitar essa situação, alguns sistemas levam em conta quem possui um processo, 
antes de escalonar sua execução. Nesse modelo, cada usuário recebe uma fração da CPU e 
o escalonador seleciona os processos de maneira a impor essa fração. Assim, se foram pro- 
metidos 50% da CPU a dois usuários, cada um receberá isso, independentemente de quantos 
processos tiverem iniciado. 

Como exemplo, considere um sistema com dois usuários, cada um com promessa de 
50% da CPU. O usuário 1 tem quatro processos, 4, B, Ce D, e o usuário 2 tem apenas 1 pro- 
cesso, E. Se for usado o escalonamento round-robin, uma possível sequência de execução que 
atende todas as restrições é a seguinte: 


AEBECEDEAEBECEDE.. 


Por outro lado, se o usuário 1 recebesse duas vezes o tempo da CPU em relação ao 
usuário 2, poderíamos obter: 


ABECDEABECDE.. 


É claro que existem muitas outras possibilidades que podem ser exploradas, dependen- 
do de qual seja a noção de imparcialidade. 


Escalonamento em sistemas de tempo real 


Um sistema de tempo real é aquele em que o tempo desempenha um papel fundamental. 
Normalmente, um ou mais dispositivos físicos externos ao computador geram estímulos e o 
computador deve interagir apropriadamente a eles, dentro de um período de tempo fixo. Por 
exemplo, o computador em um CD player recebe os bits à medida que eles vêm da unidade 
de disco e precisa convertê-los em música dentro de um intervalo de tempo limitado. Se o cál- 
culo demorar muito, a música soará estranha. Outros sistemas de tempo real servem para mo- 
nitorar pacientes na unidade de terapia intensiva de um hospital, para piloto automático em 
uma aeronave e para controle de robôs em uma fábrica automatizada. Em todos esses casos, 
receber a resposta certa, mas muito tarde, frequentemente é tão ruim quanto não recebê-la. 
Os sistemas de tempo real geralmente são classificados como de tempo real rígido, 
(hard real time) significando que há prazos finais absolutos a serem cumpridos, e de tempo 
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real relaxado ou não-rígido (soft real time), significando que perder um prazo final ocasio- 
nalmente é indesejável, mas tolerável. Em ambos os casos, o comportamento de tempo real 
é obtido dividindo-se o programa em vários processos, cujo comportamento é previsível e 
conhecido antecipadamente. Geralmente, esses processos têm vida curta e podem ser execu- 
tados até o fim em menos de um segundo. Quando um evento externo é detectado, é tarefa 
do escalonador agendar a execução dos processos de tal maneira que todos os prazos finais 
sejam cumpridos. 

Os eventos a que um sistema de tempo real responde podem ser classificados mais espe- 
cificamente como periódicos (ocorrendo em intervalos regulares) ou aperiódicos (ocorrendo 
de maneira imprevisível). Um sistema pode ter de responder a vários fluxos de evento perió- 
dicos. Dependendo de quanto tempo cada evento exigir para processamento, talvez nem seja 
possível tratar de todos eles. Por exemplo, se houver m eventos periódicos e o evento i ocorrer 
com um período P, e exigir C, segundos de tempo da CPU para tratar de cada evento, então a 
carga só poderá ser manipulada se 


Um sistema tempo real que satisfaz esse critério é conhecido como sistema escalonável. 

Como exemplo, considere um sistema de tempo real não-rígido com três eventos perió- 
dicos, com períodos de 100, 200 e 500 ms, respectivamente. Se esses eventos exigirem 50, 30 
e 100 ms de tempo de CPU por evento, respectivamente, o sistema será escalonável porque 
0,5 + 0,15 + 0,2 < 1. Se for adicionado um quarto evento, com um período de 1 s, o sistema 
continuará sendo escalonável, desde que esse evento não precise de mais de 150 ms de tempo 
de CPU por ocorrência. Nesse cálculo, está implícita a suposição de que a sobrecarga de cha- 
veamento de contexto é tão pequena que pode ser ignorada. 

Os algoritmos de escalonamento de tempo real podem ser estáticos ou dinâmicos. O 
primeiro toma suas decisões de escalonamento antes que o sistema comece a executar. O úl- 
timo toma suas decisões de escalonamento em tempo de execução. O escalonamento estático 
só funciona quando existem, antecipadamente, informações disponíveis confiáveis sobre o 
trabalho necessário a ser feito e todos os prazos finais que precisam ser cumpridos. Os algo- 
ritmos de escalonamento dinâmicos não têm essas restrições. 


Política versus mecanismo 


Até agora, admitimos tacitamente que todos os processos no sistema pertencem a usuários 
diferentes e assim estão competindo pela CPU. Embora isso frequentemente seja verdadeiro, 
às vezes acontece de um processo ter muitos filhos executando sob seu controle. Por exemplo, 
um processo de sistema de gerenciamento de banco de dados pode criar muitos filhos. Cada 
filho pode estar trabalhando em um pedido diferente ou cada um pode ter alguma função 
específica para executar (análise de consulta, acesso a disco etc.). É plenamente possível que 
o processo principal tenha uma excelente noção de quais de seus filhos são os mais impor- 
tantes (ou os mais críticos quanto ao tempo) e quais são menos importantes. Infelizmente, 
nenhum dos escalonadores discutidos anteriormente aceita qualquer informação de processos 
de usuário sobre decisões de escalonamento. Como resultado, o escalonador raramente faz a 
melhor escolha. 

A solução para esse problema é separar o mecanismo de escalonamento da políti- 
ca de escalonamento. Isso significa que o algoritmo de escalonamento é parametrizado 
de alguma maneira, mas os parâmetros podem ser fornecidos pelos processos de usuário. 
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Consideremos novamente o exemplo do banco de dados. Suponha que o núcleo utilize um 
algoritmo de escalonamento por prioridade, mas forneça uma chamada de sistema por meio 
da qual um processo pode configurar (e alterar) as prioridades de seus filhos. Assim, o pai 
pode controlar com detalhes como seus filhos são postos em execução, mesmo que não faça 
a escalonamento em si. Aqui, o mecanismo está no núcleo, mas a política é configurada por 
um processo de usuário. 


Escalonamento de threads 


Quando vários processos têm múltiplas threads cada um, temos dois níveis de paralelismo 
presentes: processos e threads. O escalonamento em tais sistemas difere substancialmente, 
dependendo se as threads são suportadas em nível de usuário ou em nível de núcleo (ou 
ambos). 

Vamos considerar primeiro as threads em nível de usuário. Como o núcleo não tem co- 
nhecimento da existência de threads, ele funciona normalmente, selecionando um processo, 
digamos, A, e dando a esse processo o controle de seu quantum. Dentro do processo A existe 
um escalonador de threads que seleciona qual thread vai executar, digamos, A7. Como não 
existem interrupções de relógio para multiprogramar as threads, essa thread pode continuar 
executando o quanto quiser. Se ela consumir o quantum inteiro do processo, o núcleo selecio- 
nará outro processo para executar. 

Quando o processo A finalmente for executado outra vez, a thread Al retomará sua 
execução. Ela continuará a consumir todo o tempo de A, até que termine. Entretanto, seu 
comportamento anti-social não afetará outros processos. Eles receberão o que o escalonador 
considerar como sua fatia apropriada, independente do que estiver acontecendo dentro do 
processo 4. 

Agora, considere o caso em que as threads de A têm relativamente pouco trabalho a 
fazer por rajada de CPU, por exemplo, 5 ms de trabalho, dentro de um quantum de 50 ms. 
Conseqiientemente, cada uma deles é executada por um pouco de tempo e, então, devolve a 
CPU para o escalonador de threads. Isso poder levar à segiiência AI, A2, A3, A1, A2, A3, Al, 
A2, A3, Al, antes do núcleo comutar para o processo B. Essa situação está ilustrada na Figura 
2-28(a). 


Processo A Processo B Processo A Processo B 


Ordem em 
que as threads 
são executadas 


2. O escalo- 
nador em 
nível de 
usuário INE E/N E 
(runtime) NA 
seleciona 
uma thread 1. O núcleo seleciona 1. O núcleo seleciona E 
um processo uma thread 
Possível: A1, A2, A3, A1, A2, A3 Possível: A1, A2, A3, A1, A2, A3 
Impossível: A1, B1, A2, B2, A3, B3 Também possível: A1, B1, A2, B2, A3, B3 


(a) (b) 


Figura 2-28 (a) Possível escalonamento de threads em nível de usuário com um quantum 
de processo de 50 ms e threads executando 5 ms por rajada de CPU. (b) Possível escalona- 
mento de threads em nível de núcleo com as mesmas características de (a). 
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O algoritmo de escalonamento usado pode ser qualquer um dos descritos anteriormen- 
te. Na prática, o escalonamento round-robin e o escalonamento por prioridade são os mais 
comuns. A única restrição é a ausência de um relógio para interromper uma thread que preci- 
sa ser executado por muito tempo. 

Considere agora a situação das threads em nível de núcleo. Aqui, o núcleo seleciona 
uma thread em particular para executar. Ele não precisa levar em conta a qual processo a 
thread pertence, mas pode fazer isso, se quiser. A thread recebe um quantum e, caso exceda 
esse quantum, é obrigatoriamente suspenso. Com um quantum de 50 ms, mas com threads 
que são bloqueadas após 5 ms, a ordem das threads para um período de 30 ms pode ser Aí, 
B1, A2, B2, A3, B3, algo impossível com esses parâmetros e threads em nível de usuário. Essa 
situação está parcialmente representada na Figura 2-28(b). 

Uma diferença importante entre threads em nível de usuário e threads em nível de nú- 
cleo é o desempenho. Fazer um chaveamento de threads em nível de usuário exige algumas 
instruções de máquina. As threads em nível de núcleo exigem uma troca de contexto com- 
pleta, alterando o mapa de memória e invalidando a cache, o que é muitas vezes mais lento. 
Por outro lado, com threads em nível de núcleo, bloquear uma thread em E/S não suspende o 
processo inteiro, como acontece com threads em nível de usuário. 

Como o núcleo sabe que chavear de uma thread no processo A para uma thread no 
processo B é mais dispendioso do que executar uma segunda thread no processo A (devi- 
do à necessidade da troca do mapa de memória e de invalidar a cache), ele pode levar essa 
informação em conta ao tomar uma decisão. Por exemplo, dadas duas threads igualmente 
importantes, com cada uma delas pertencente ao mesmo processo que uma thread que acabou 
de ser bloqueada e outra pertencente a um processo diferente, a preferência pode ser dada ao 
primeiro. 

Outro fator importante a considerar é que as threads em nível de usuário podem em- 
pregar um escalonamento específico do aplicativo. Por exemplo, considere um servidor web 
que possui uma thread “despachante” para aceitar e distribuir os pedidos recebidos para 
threads operárias. Suponha que uma thread operária tenha acabado de ser bloqueada e que a 
thread despachante e duas threads operárias estejam prontas. Quem deve ser executado em 
seguida? O escalonador, sabendo o que todas as threads fazem, pode selecionar facilmente 
a despachante, para permitir que se possa pôr outra operária em execução. Essa estratégia 
maximiza o volume de paralelismo em um ambiente onde as operárias são fregientemente 
bloqueadas em E/S de disco. Com threads em nível de núcleo, o núcleo nunca saberia o que 
cada thread faz (embora eles pudessem receber diferentes prioridades). Em geral, contudo, 
os escalonadores de threads específicos do aplicativo podem otimizar sua execução melhor 
do que o núcleo. 


VISÃO GERAL DOS PROCESSOS NO MINIX 3 


Tendo completado nosso estudo sobre os princípios do gerenciamento de processos, da co- 
municação entre processos e do escalonamento, podemos ver agora como eles são aplicados 
no MINIX 3. Ao contrário do UNIX, cujo núcleo é um programa monolítico e não dividido 
em módulos, o MINIX 3 é uma coleção de processos que se comunicam entre si e também 
com processos de usuário, utilizando uma única primitiva de comunicação entre processos 
— a passagem de mensagens. Esse projeto proporciona uma estrutura mais flexível e modular, 
tornando fácil, por exemplo, substituir o sistema de arquivos inteiro por outro completamente 
diferente, sem nem mesmo precisar recompilar o núcleo. 
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2.5.1 


À estrutura interna do MINIX 3 


Vamos começar nosso estudo do MINIX 3 com uma visão geral do sistema. O MINIX 3 é 
estruturado em quatro camadas, cada uma executando uma função bem-definida. As quatro 
camadas estão ilustradas na Figura 2-29. 


Camada 
4 Init Processo Processo Processo Processos 
de usuário | de usuário | de usuário de usuário 
3 Sistema | Servidor de | Servidor Processos | Modo 
de arquivos]informações| de rede de servidor | usuário 
2 Driver Driver Drivers de 
TTY Ethernet dispositivo 


1 Núcl | Tarefa ı Tarefa Núcl Modo 
EICIGO de relógio de sistema UCIcO núcleo 


Figura 2-29 O MINIX 3 é estruturado em quatro camadas. Apenas os processos da camada 
inferior podem usar instruções privilegiadas (de modo núcleo). 


O núcleo, na camada inferior, escalona os processos e gerencia as transições entre os 
estados pronto, executando e bloqueado da Figura 2-2. O núcleo também manipula todas as 
mensagens entre processos. O tratamento de mensagens exige verificar os destinos válidos, 
localizar os buffers de envio e recepção na memória física e copiar bytes do remetente para o 
destinatário. Outra parte do núcleo é o suporte para o acesso às portas de E/S e interrupções, 
o que nos processadores modernos exige o uso de instruções privilegiadas do modo núcleo, 
não disponíveis para processos normais. 

Além do núcleo em si, essa camada contém dois módulos que funcionam de modo 
semelhante aos drivers de dispositivo. A tarefa de relógio é um driver de dispositivo de E/S, 
pois interage com o hardware que gera sinais de temporização, mas não é acessível para o 
usuário, como um driver de disco ou de linha de comunicações — ele faz interface apenas 
com o núcleo. 

Uma das principais funções da camada 1 é fornecer um conjunto de chamadas de nú- 
cleo privilegiadas para os drivers e servidores que estão acima dela. Isso inclui ler e escrever 
em portas de E/S, copiar dados entre espaços de endereçamento etc. A implementação dessas 
chamadas é feita pela tarefa de sistema. Embora a tarefa de sistema e a tarefa de relógio 
sejam compiladas no espaço de endereçamento do núcleo, seu escalonamento é feito como 
processos separados e elas têm suas próprias áreas de pilha. 

A maior parte do núcleo e as tarefas de relógio e de sistema são escritas em C. Entre- 
tanto, uma pequena parte do núcleo é escrita em linguagem assembly, como aquelas que 
trabalham com o tratamento de interrupções, com o mecanismo de baixo nível do chavea- 
mento de contexto entre processos (salvar e restaurar registradores e coisas parecidas) e com 
as partes de baixo nível da manipulação do hardware MMU (Memory Management Unit) do 
processador. De modo geral, o código em linguagem assembly diz respeito as partes do nú- 
cleo que interagem diretamente com o hardware em um nível muito baixo e que não podem 
ser expressas em C. Essas partes devem ser reescritas quando o MINIX 3 é portado para uma 
nova arquitetura. 

As três camadas acima do núcleo poderiam ser consideradas como uma só, pois o nú- 
cleo trata de todas elas fundamentalmente da mesma maneira. Cada uma delas está limitada 
às instruções do modo usuário e tem seu escalonamento feito pelo núcleo. Nenhuma delas 


CAPÍTULO 2 e PROCESSOS 121 


pode acessar E/S diretamente. Além disso, nenhuma delas pode acessar memória fora dos 
segmentos (zonas) dedicados a elas. 

Entretanto, os processos podem ter privilégios especiais (como a capacidade de fazer 
chamadas de núcleo). Essa é a diferença real entre os processos nas camadas 2, 3 e 4. Os pro- 
cessos da camada 2 têm a maioria dos privilégios, os da camada 3 têm alguns e os da camada 
4 não têm nenhum privilégio especial. Por exemplo, os processos da camada 2, chamados de 
drivers de dispositivo, podem pedir para que a tarefa de sistema leia ou escreva dados em 
portas de E/S em seu nome. É necessário um driver para cada tipo de dispositivo, incluindo 
discos, impressoras, terminais e interfaces de rede. Se outros dispositivos de E/S estiverem 
presentes, também será necessário um driver para cada um deles. Os drivers de dispositivo 
também podem fazer outras chamadas de núcleo, como solicitar que dados lidos recentemen- 
te sejam copiados para o espaço de endereçamento de um processo diferente. 

A terceira camada contém os servidores, processos que fornecem serviços úteis para os 
processos de usuário. Dois servidores são fundamentais. O gerenciador de processos (PM 
— Process Manager) executa todas as chamadas de sistema do MINIX 3 que envolvem iniciar 
ou interromper a execução de processo, como fork, exec e exit, assim como chamadas de sis- 
tema relacionadas a sinais, como alarm e kill, que podem alterar o estado de execução de um 
processo. O gerenciador de processos também é responsável pelo gerenciamento de memó- 
ria, por exemplo, com a chamada de sistema brk. O sistema de arquivos (FS — File System) 
executa todas as chamadas de sistema de arquivo, como read, mount e chdir. 

É importante entender a diferença entre chamadas de núcleo e chamadas de sistema do 
POSIX. As chamadas de núcleo são funções de baixo nível fornecidas pela tarefa de sistema 
para permitir que os drivers e servidores realizem seu trabalho. Ler uma porta de E/S de 
hardware é uma chamada de núcleo típica. Em contraste, as chamadas de sistema do POSIX, 
como read, fork e unlink, são chamadas de alto nível definidas pelo padrão POSIX e estão 
disponíveis para programas de usuário na camada 4. Os programas de usuário podem conter 
várias chamadas POSIX, mas nenhuma chamada de núcleo. Ocasionalmente, quando não to- 
mamos cuidado com nossa linguagem, podemos chamar uma chamada de núcleo de chamada 
de sistema. Os mecanismos usados para isso são semelhantes e as chamadas de núcleo podem 
ser consideradas um conjunto especial das chamadas de sistema. 

Além do gerenciador de processos e do sistema de arquivos, existem outros servidores 
na camada 3. Eles executam funções específicas do MINIX 3. É válido afirmar que a fun- 
cionalidade do gerenciador de processos e do sistema de arquivos é encontrada em qualquer 
sistema operacional. O servidor de informações (IS — Information Server) trata de tarefas 
como fornecer informações de depuração e status sobre outros drivers e servidores, algo que 
é mais necessário em um sistema como o MINIX 3 (que é projetado para experiências) do 
que para um sistema operacional comercial, que os usuários não podem alterar. O servidor 
de reencarnação (RS — Reincarnation Server) inicia (e, se necessário, reinicia) drivers de 
dispositivo que não são carregados em memória ao mesmo tempo que o núcleo. Em particu- 
lar, se um driver falha durante sua execução, o servidor de reencarnação detecta essa falha, 
elimina o driver, caso ainda não esteja eliminado, e inicia uma cópia nova dele, tornando o 
sistema altamente tolerante a falhas. Essa funcionalidade é ausente na maioria dos sistemas 
operacionais. Em um sistema em rede, o servidor de rede (inet) também está no nível 3. Os 
servidores não podem fazer operações de E/S diretamente, mas podem se comunicar com 
drivers para solicitá-las. Os servidores também podem se comunicar com o núcleo por inter- 
médio da tarefa de sistema. 

Conforme observamos no início do Capítulo 1, os sistemas operacionais fazem duas 
coisas: gerenciam recursos e fornecem uma máquina estendida, implementando chamadas 
de sistema. No MINIX 3, o gerenciamento de recursos é feito principalmente pelos drivers 
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da camada 2, com a ajuda da camada do núcleo, quando é exigido acesso privilegiado às por- 
tas de E/S ou ao sistema de interrupção. A interpretação da chamada de sistema é feita pelo 
gerenciador de processos e pelos servidores de sistema de arquivos na camada 3. O sistema 
de arquivos foi cuidadosamente projetado como um “servidor” de arquivos e, com pequenas 
alterações, poderia ser movido para uma máquina remota. 

O sistema não precisa ser recompilado para incluir mais servidores. O gerenciador 
de processos e o sistema de arquivos podem ser complementados com o servidor de rede 
e outros, anexando-os conforme for necessário, quando o MINIX 3 iniciar ou depois. Os 
drivers de dispositivo são normalmente executados na inicialização do sistema, mas tam- 
bém podem ser ativados posteriormente. Tanto os drivers de dispositivo como os servidores 
são compilados e armazenados em disco como arquivos executáveis normais, mas quando 
iniciados apropriadamente, eles têm acesso garantido aos privilégios especiais necessários. 
Um programa de usuário chamado service fornece uma interface para o servidor de reencar- 
nação que o gerencia. Embora os drivers e servidores sejam processos independentes, eles 
diferem dos processos de usuário porque, normalmente, nunca terminam enquanto o sistema 
está ativo. 

Vamos nos referir fregiientemente aos drivers e servidores das camadas 2 e 3 como 
processos de sistema. Com certeza, os processos de sistema fazem parte do sistema opera- 
cional. Eles não pertecem a nenhum usuário e muitos, se não todos eles, serão ativados antes 
que o primeiro usuário se conecte. Outra diferença entre processos de sistema e processos de 
usuário é que os primeiros têm prioridade de execução mais alta do que estes. Na verdade, 
normalmente os drivers têm prioridade de execução mais alta do que os servidores, mas isso 
não é automático. A prioridade de execução é atribuída caso a caso no MINIX 3; é possível 
que um driver que atende um dispositivo lento receba prioridade menor do que um servidor 
que precisa responder rapidamente. 

Finalmente, a camada 4 contém todos os processos de usuário — shells, editores, com- 
piladores e programas executáveis (a.out) escritos pelo usuário. Muitos processos de usuário 
aparecem e desaparecem, à medida que os usuários se conectam, fazem seu trabalho e se 
desconectam. Normalmente, um sistema em execução tem alguns processos que são ativa- 
dos quando o sistema é inicializado e que são executados eternamente. Um deles é init, o 
qual descreveremos na próxima seção. Além disso, vários daemons provavelmente estarão 
em execução. Um daemon é um processo de segundo plano executado periodicamente ou 
que espera pela ocorrência de algum evento, como a chegada de dados da rede. De certa for- 
ma, um daemon é um servidor iniciado independentemente e executado como um processo 
de usuário. Assim como os servidores verdadeiros, ativados no momento da inicialização, é 
possível configurar um daemon com uma prioridade mais alta do que os processos de usuá- 
rio normais. 

É necessária uma observação sobre os termos tarefa e driver de dispositivo. Nas ver- 
sões antigas do MINIX, todos os drivers de dispositivo eram compilados junto com o núcleo, 
o que propiciava a eles acesso às estruturas de dados pertencentes ao núcleo e uns aos outros. 
Todos eles também podiam acessar portas de E/S diretamente. Eles eram referidos como “ta- 
refas” para distingui-los de processos em espaço do usuário puros. No MINIX 3, os drivers 
de dispositivo foram implementados completamente em espaço de usuário. A única exceção 
é a tarefa de relógio, que com certeza não é um driver de dispositivo no mesmo sentido que os 
drivers que podem ser acessados pelos processos de usuário por meio de arquivos de disposi- 
tivo. No texto, nos esmeramos para usar o termo “tarefa” somente aos nos referirmos à tarefa 
de relógio ou à tarefa de sistema, ambas compiladas no núcleo para funcionar. Substituímos 
cuidadosamente a palavra tarefa por driver de dispositivo onde nos referimos aos drivers de 
dispositivo em espaço de usuário. Entretanto, os nomes de função, os nomes de variável e 
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os comentários no código-fonte não foram atualizados com tanto cuidado. Assim, quando 
examinar o código-fonte, durante seu estudo do MINIX 3, você poderá encontrar a palavra 
tarefa, onde queremos dizer driver de dispositivo. 


Gerenciamento de processos no MINIX 3 


No MINIX 3, os processos seguem o modelo genérico de processo descrito em detalhes, 
anteriormente, neste capítulo. Os processos podem criar subprocessos, os quais, por sua vez, 
podem criar outros subprocessos, produzindo uma árvore de processos. Na verdade, todos 
os processos de usuário no sistema inteiro fazem parte de uma única árvore, com init (veja 
Figura 2-29) na raiz. Os servidores e os drivers de dispositivo são um caso especial já que 
alguns deles devem ser executados antes de qualquer processo de usuário e mesmo do pro- 
cesso init. 


Inicialização do MINIX 3 


Como um sistema operacional é inicializado? Nas próximas páginas, resumiremos a seqüên- 
cia de inicialização do MINIX 3. Para ver como alguns outros sistemas operacionais fazem 
isso, consulte Dodge et al. (2005). 

Na maioria dos computadores com dispositivos de disco, existe uma hierarquia de disco 
de inicialização (boot disk). Normalmente, se um disquete estiver na primeira unidade de 
disquete, ele será o disco de inicialização. Se nenhum disquete estiver presente e houver um 
CD-ROM na primeira unidade de CD-ROM, ele se tornará o disco de inicialização. Se não 
houver nem disquete nem CD-ROM presente, a primeira unidade de disco rígido se tornará o 
disco de inicialização. A ordem dessa hierarquia pode ser configurada entrando-se na BIOS 
imediatamente após ligar o computador. Dispositivos adicionais, especialmente outros dispo- 
sitivos de armazenamento removíveis, também podem ser usados. 

Quando o computador é ligado, se o dispositivo de inicialização é um disquete, o har- 
dware lê o primeiro setor da primeira trilha para a memória e executa o código lá encontrado. 
Em um disquete, esse setor contém o programa de inicialização (bootstrap). Ele deve ser 
muito pequeno, pois tem de caber em um setor (512 bytes). O programa de inicialização do 
MINIX 3, na verdade, carrega para memória um programa maior que 512 bytes, o boot, que, 
por sua vez, carrega o sistema operacional propriamente dito. 

Em contraste, os discos rígidos exigem um passo intermediário. Um disco rígido é di- 
vidido em partições e o primeiro setor de um disco rígido contém um pequeno programa e a 
tabela de partição do disco. Coletivamente, essas duas partes são chamadas de registro de 
inicialização mestre (master boot record — MBR). A parte referente ao programa é executada 
para ler a tabela de partição e selecionar a partição ativa. A partição ativa tem um programa 
de inicialização em seu primeiro setor que é, então, carregado e executado para localizar e 
iniciar uma cópia do boot na partição, exatamente como acontece ao se inicializar a partir de 
um disquete. 

Os CD-ROMs apareceram depois dos disquetes e dos discos rígidos na história dos 
computadores e quando está presente suporte para inicialização a partir de um CD-ROM, ele 
é capaz de mais do que apenas carregar um setor. Um computador que suporta inicialização a 
partir de um CD-ROM pode carregar um grande bloco de dados na memória, imediatamente. 
Normalmente, o que é carregado do CD-ROM é uma cópia exata de um disquete de inicia- 
lização, a qual é colocada na memória e usada como se fosse um disco em RAM (ramdisk). 
Após esse passo, o controle é transferido para o disco em RAM e a inicialização continua 
exatamente como se um disquete físico fosse o dispositivo de inicialização. Em um computa- 
dor mais antigo, que tenha uma unidade de CD-ROM, mas não suporte inicialização a partir 
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de um CD-ROM, a imagem do disquete de inicialização pode ser copiada em um disquete, o 
qual pode então ser usado para iniciar o sistema. O CD-ROM deve estar na respectiva unida- 
de, é claro, pois a imagem do disquete de inicialização espera isso. 

Em qualquer caso, o programa de boot do MINIX 3 procura no disquete ou na partição 
um arquivo composto por várias partes e as carrega individualmente na memória, nos locais 
adequados. Essa é a imagem de boot (boot image). As partes incluem o núcleo (o qual inclui 
a tarefa de relógio e a tarefa de sistema), o gerenciador de memória e o sistema de arquivos. 
Além disso, pelo menos um driver de disco deve ser carregado como parte da imagem de 
boot. Existem vários outros programas carregados na imagem de boot. Isso inclui o servidor 
de reencarnação, o disco em RAM, o console e drivers de log e init. 

Deve ser bastante enfatizado que todas as partes da imagem de boot são programas 
separados. Após o núcleo básico, o gerenciador de processos e o sistema de arquivos terem 
sido carregados, muitas outras partes podem ser carregadas separadamente. Uma exceção é o 
servidor de reencarnação. Ele deve fazer parte da imagem de boot. Esse servidor concede aos 
processos normais, carregados após a inicialização, as prioridades e privilégios especiais que 
os transformam em processos de sistema. Ele também pode reiniciar um driver danificado, o 
que explica seu nome. Conforme mencionado anteriormente, pelo menos um driver de disco 
é fundamental. Se o sistema de arquivos raiz for copiado em um disco de RAM, o driver de 
memória também será exigido; caso contrário, ele pode ser carregado posteriormente. Os dri- 
vers tty e log são opcionais na imagem de boot. Eles são carregados antecipadamente porque 
é útil exibir mensagens no console e salvar informações em um log no começo do processo 
de inicialização. Certamente, init poderia ser carregado posteriormente, mas ele controla a 
configuração inicial do sistema e foi muito mais fácil simplesmente incluí-lo no arquivo de 
imagem de boot. 

A inicialização não é uma operação simples. As operações que estão nos domínios do 
driver de disco e do sistema de arquivos devem ser executadas pelo programa de boot antes 
que essas partes do sistema estejam ativas. Em uma seção posterior, entraremos nos detalhes 
sobre como o MINIX 3 é iniciado. Por enquanto, basta dizer que, uma vez terminada a ope- 
ração de carregamento, o núcleo começa a ser executado. 

Durante sua fase de inicialização, o núcleo inicia as tarefas de sistema e de relógio e 
depois o gerenciador de processos e o sistema de arquivos. O gerenciador de processos e 
o sistema de arquivos cooperam então na inicialização de outros servidores e drivers que 
fazem parte da imagem de boot. Quando todos eles tiverem sido executados e inicializados, 
serão bloqueados, na espera de algo para fazer. O escalonamento do MINIX 3 é baseado em 
prioridade. Somente quando todas as tarefas, drivers e servidores carregados na imagem de 
boot tiverem sido bloqueados é que init, o primeiro processo de usuário, será executado. Os 
componentes de sistema carregados com a imagem de boot ou durante a inicialização apare- 
cem na Figura 2-30. 


Inicialização da árvore de processos 


Init é o primeiro processo de usuário e o último processo carregado como parte da imagem de 
boot. Você poderia pensar que o princípio da construção de uma árvore de processos, como a 
da Figura 1-5, acontece quando init começa a ser executado. Bem, não exatamente. Isso seria 
verdade em um sistema operacional convencional, mas o MINIX 3 é diferente. Primeiramen- 
te, já existem vários processos de sistema em execução quando init começa a executar. As 
tarefas CLOCK e SYSTEM executadas dentro do núcleo são processos exclusivos, invisíveis 
fora do núcleo. Elas não recebem PIDs e não são consideradas parte de nenhuma árvore de 
processos. O gerenciador de processos é o primeiro processo a ser executado no espaço de 
usuário; ele recebe o PID O e não é filho nem pai de nenhum outro processo. O servidor de 
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Componente | Descrição Carregado por 
kernel Núcleo + tarefas de relógio e de sistema (na imagem de boot) 
pm Gerenciador de processos (na imagem de boot) 
fs Sistema de arquivos (na imagem de boot) 
rs (Rejinicia servidores e drivers (na imagem de boot) 
memory Driver de disco de RAM (na imagem de boot) 
log Registra informações de log (na imagem de boot) 
tty Driver de console e teclado (na imagem de boot) 
driver Driver de disco (at, bios ou floppy) (na imagem de boot) 
init pai de todos os processos de usuário (na imagem de boot) 
floppy Driver de disquete (se inicializado a partir de /etc/re 

disco rígido) 
is Servidor de informação (para informações de /etc/rc 

depuração) 
cmos Lê o relógio da CMOS para configurar a hora /etc/rc 
random Gerador de números aleatórios /etc/rc 
printer Driver de impressora /etc/re 

Figura 2-30 Alguns componentes de sistema importantes do MINIX 3. Outros, como um 


driver Ethernet e o servidor inet, também podem estar presentes. 


reencarnação se torna pai de todos os outros processos iniciados a partir da imagem de boot 
(por exemplo, os drivers e servidores). A lógica disso é que o servidor de reencarnação é o 
processo que deve ser informado se qualquer um deles precisar ser reiniciado. 

Conforme veremos, mesmo depois que init começa a ser executado, existem diferen- 
ças entre a maneira como uma árvore de processos é construída no MINIX 3 e na forma 
convencional. Em um sistema do tipo UNIX, o programa init recebe o PID 1 e mesmo que 
init não seja o primeiro processo a ser executado, o PID 1 tradicional é reservado para ele no 
MINIX 3. Assim como acontece em todos os processos de espaço de usuário na imagem de 
boot (exceto o gerenciador de processos), init se torna um dos filhos do servidor de reencar- 
nação. Assim como em um sistema tipo UNIX padrão, init executa primeiro o script de shell 
fetc/rc. Esse script inicia drivers e servidores adicionais que não fazem parte da imagem de 
boot. Todo programa iniciado pelo script rc será filho de init. Um dos primeiros programas 
executados é um utilitário chamado service. O próprio utilitário service é executado como 
filho de init, conforme seria esperado. Mas, agora, mais uma vez as coisas variam em relação 
ao convencional. 

Service é a interface do usuário com o servidor de reencarnação. O servidor de reen- 
carnação inicia um programa normal e o converte em processo de sistema. Ele inicia floppy 
(se não foi usado na inicialização do sistema), cmos (que é necessário para ler o relógio de 
tempo real) e is, o servidor de informações, que gerencia as informações de depuração (core 
dump) produzidas pelo pressionamento das teclas de função (F1, F2 etc.) no teclado do con- 
sole. Uma das ações do servidor de reencarnação é adotar como filhos todos os processos de 
sistema, exceto o gerenciador de processos. 

Após o driver de dispositivo cmos ter sido iniciado, o script rc pode acertar o relógio 
de tempo real. Até esse ponto, todos os arquivos necessários devem ser encontrados no dis- 
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positivo-raiz. Os servidores e drivers necessários estão inicialmente no diretório /sbin; outros 
comandos necessários para a inicialização estão em /bin. Quando as etapas de inicialização 
iniciais tiverem terminado, outros sistemas de arquivos, como /usr, serão montados. Uma 
função importante do script rc é verificar a existência de problemas no sistema de arquivos 
que podem ter resultado de uma falha anterior do sistema. O teste é simples — quando o siste- 
ma é desligado corretamente pela execução do comando shutdown, é escrito uma entrada no 
arquivo de histórico de login, /usr/adm/wtmp. O comando shutdown -C verifica se a última 
entrada em wtmp é uma entrada de shutdown. Se não for, supõe-se que ocorreu um desliga- 
mento anormal e o utilitário fsck é executado para verificar todos os sistemas de arquivos. 
A tarefa final de /etc/rc é iniciar daemons. Isso pode ser feito por scripts auxiliares. Se você 
examinar a saída de um comando ps axl, que mostra os PIDs e os PIDs de pai (PPIDs), verá 
que os daemons como update e usyslogd normalmente estarão entre os primeiros processos 
que são filhos de init. 

Finalmente, init lê o arquivo /etc/ttytab, que lista todos os dispositivos de terminal em 
potencial. Os dispositivos que podem ser usados como terminais de login (na distribuição 
padrão, apenas o console principal e até três consoles virtuais, mas linhas seriais e pseudo- 
terminais de rede podem ser adicionados) têm uma entrada no campo getty de /etc/ttytab e 
init cria um processo filho para cada terminal de login. Normalmente, cada filho executa 
/usr/bin/getty, que imprime uma mensagem e depois espera que um nome seja digitado. Se 
um terminal em particular exigir tratamento especial (por exemplo, uma linha discada), /etc/ 
ttytab poderá especificar um comando (como /usr/bin/stty) a ser executado para inicializar a 
linha antes de executar getty. 

Quando um usuário digita um nome para se conectar, /usr/bin/login é chamado tendo o 
nome como argumento. Login determina se uma senha é necessária e, se for, solicita e veri- 
fica a senha. Após um login bem-sucedido, o comando login executa o shell do usuário (por 
padrão, /bin/sh, mas outro shell pode ser especificado no arquivo /etc/passwd). O shell espera 
que comandos sejam digitados e cria um novo processo para cada comando. Desse modo, 
os interpretadores de comando (shells) são os filhos de init, os processos de usuário são os 
netos de init e todos os processos de usuário no sistema fazem parte de uma única árvore. Na 
verdade, exceto quanto às tarefas compiladas no núcleo e o gerenciador de processos, todos 
os processos, tanto de sistema como de usuário, formam uma árvore. Mas, ao contrário da 
árvore de processos de um sistema UNIX convencional, init não está na raiz da árvore e a 
estrutura da árvore não permite que se determine a ordem em que os processos de sistema 
foram iniciados. 

As duas principais chamadas de sistema do MINIX 3 para gerenciamento de processos 
são fork e exec. Fork é a única maneira de criar um novo processo. Exec permite que um pro- 
cesso execute um programa especificado. Quando um programa é executado, ele recebe uma 
parte da memória, cujo tamanho é especificado no cabeçalho do arquivo do programa. Ele 
mantém essa quantidade de memória durante toda sua execução, embora a distribuição entre 
segmento de dados, segmento de pilha e zonas não utilizadas possa variar quando o processo 
é executado. 

Todas as informações sobre um processo são mantidas na tabela de processos, que é di- 
vidida entre o núcleo, o gerenciador de processos e o sistema de arquivos, cada um dos quais 
tendo os campos necessários. Quando um novo processo começa a existir (pelo uso de fork) 
ou quando um processo antigo termina (pelo uso de exit ou por meio de um sinal), o gerencia- 
dor de processos primeiro atualiza sua parte da tabela de processos e depois envia mensagens 
para o sistema de arquivos e para o núcleo, dizendo a eles para que façam o mesmo. 
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2.5.3 Comunicação entre processos no MINIX 3 


São fornecidas três primitivas para enviar e receber mensagens. Elas são chamadas pelas 
funções de biblioteca. Em linguagem C: 


send(dest, &message); 

para enviar uma mensagem ao processo destino dest, 
receive(source, &message); 

para receber uma mensagem do processo fonte source (ou ANY), e 
sendrec(src. dst, &message); 


para enviar uma mensagem e esperar uma resposta do mesmo processo. O segundo parâmetro 
de cada chamada é o endereço local dos dados da mensagem. O mecanismo de passagem de 
mensagens no núcleo copia a mensagem do remetente no destinatário. A resposta (de sen- 
drec) se sobrepõe à mensagem original. Em princípio, esse mecanismo do núcleo poderia ser 
substituído por uma função que copiasse mensagens, por meio de uma rede, para uma função 
correspondente em outra máquina, implementando um sistema distribuído. Na prática, isso 
seria complicado pelo fato de o conteúdo dessa mensagem, às vezes, incluir ponteiros para 
estruturas de dados grandes e um sistema distribuído também teria de providenciar a cópia 
dos dados em si pela rede. 

Cada tarefa, driver ou processo servidor pode trocar mensagens apenas com determi- 
nados processos. Os detalhes de como isso é imposto serão descritos posteriormente. O fluxo 
usual de mensagens é para baixo, nas camadas da Figura 2-19, ainda, as mensagens podem 
ser entre processos de uma mesma camada ou entre processos de camadas adjacentes. Os 
processos de usuário não podem enviar mensagens uns para os outros. Os processos de usuá- 
rio da camada 4 podem enviar mensagens para servidores na camada 3 e estes podem enviar 
mensagens para drivers na camada 2. 

Quando um processo envia uma mensagem para um processo que não está esperando 
uma mensagem, o remetente é bloqueado até que o destino execute uma operação receive. 
Em outras palavras, o MINIX 3 utiliza o método de rendez-vous para evitar os problemas do 
armazenamento em buffer de mensagens enviadas, mas ainda não recebidas. A vantagem des- 
sa estratégia é que ela é simples e elimina a necessidade de gerenciamento de buffer (incluin- 
do a possibilidade de esgotar os buffers disponíveis). Além disso, como todas as mensagens 
têm tamanho fixo, determinado no momento da compilação, os erros de transbordamento de 
buffer (overrun), uma fonte de erros comum, são evitados estruturalmente, por construção. 

O objetivo básico das restrições nas trocas de mensagens é que, se o processo A puder 
gerar uma operação send, ou sendrec, direcionada ao processo B, então o processo B poderá 
chamar receive com A designado como remetente, mas B não deve executar a operação send 
para A. Obviamente, se A tentar executar a operação send para B e for bloqueado, e B tentar 
executar a operação send para A e for bloqueado, teremos um impasse (deadlock). O recurso 
que cada um precisaria para completar as operações não é um recurso físico, como um dis- 
positivo de E/S, mas uma chamada para receive por parte do destino da mensagem. Teremos 
mais a dizer sobre impasses, no Capítulo 3. 

Ocasionalmente, é necessário algo diferente de um bloqueio de mensagem. Existe outra 
importante primitiva de passagem de mensagens. Ela é chamada pela função de biblioteca 


notify(dest); 
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e é usada quando um processo precisa informar outro processo que algo importante aconte- 
ceu. Uma operação notify não causa bloqueio, o que significa que o remetente continua a exe- 
cutar, esteja o destinatário esperando ou não. Como isso não causa bloqueio, uma notificação 
evita a possibilidade de impasse na troca de mensagens. 

O mecanismo de mensagem é usado para distribuir uma notificação, mas a informação 
transmitida é limitada. No caso geral, a mensagem contém apenas a identidade do remetente 
e uma indicação de tempo (timestamp) adicionada pelo núcleo. Às vezes, basta isso. Por 
exemplo, o teclado usa uma chamada de notify quando é pressionada uma das teclas de função 
(Fla F12 e de F1 a F12 em conjunto com a tecla shift). No MINIX 3, as teclas de função são 
usadas para gerar informações de depuração. O driver Ethernet é um exemplo de processo 
que gera apenas um tipo de informação de depuração e não necessita nenhuma outra comu- 
nicação com o driver de console. Em outros casos, a notificação não é suficiente, pois ao 
recebê-la, o processo de destino pode enviar uma mensagem para o remetente da notificação 
para pedir mais informações. 

Há um motivo para as mensagens de notificação serem tão simples. Como uma chama- 
da de notify não causa bloqueio, ela pode ser feita quando o destinatário ainda não executou 
uma operação receive. Mas a simplicidade da mensagem significa que uma notificação que 
não pôde ser recebida é facilmente armazenada, para que o destinatário possa ser informado 
sobre ela na próxima vez que chamar receive. Na verdade, basta um único bit. As notificações 
se destinam a serem usadas entre processos de sistema, os quais são normalmente em núme- 
ro relativamente pequeno. Todo processo de sistema tem um mapa de bits para notificações 
pendentes, com um bit diferente para cada processo. Assim, se o processo A precisa enviar 
uma notificação para o processo B em um momento em que o processo B não está bloqueado 
em uma recepção, o mecanismo de passagem de mensagens configura um bit que correspon- 
de a A no mapa de bits de notificações pendentes de B. Quando B finalmente executa uma 
operação receive, o primeiro passo é verificar seu mapa de bits de notificações pendentes. 
Dessa maneira, ele pode saber sobre tentativas de notificações de várias fontes. O único bit 
é suficiente para obter o conteúdo da informação da notificação. Ele informa a identidade do 
remetente e o código de passagem de mensagens no núcleo adiciona a indicação de tempo 
de quando a mensagem foi recebida. As indicações de tempo são usadas principalmente para 
verificar a expiração de temporizadores, de modo que não importa muito se a indicação de 
tempo possa ser de uma hora posterior àquela de quando o remetente tentou enviar a notifi- 
cação pela primeira vez. 

Há mais um refinamento no mecanismo de notificação. Em certos casos, é usado um 
campo adicional na mensagem de notificação. Quando a notificação é gerada para informar 
a um destinatário sobre uma interrupção, é incluído na mensagem um mapa de bits de todas 
as fontes de interrupções possíveis. E quando a notificação é proveniente da tarefa de sistema, 
um mapa de bits de todos os sinais pendentes para o destinatário faz parte da mensagem. A 
pergunta natural neste ponto é: como essa informação adicional pode ser armazenada quando a 
notificação deve ser enviada para um processo que não está tentando receber uma mensagem? 
A resposta é: esses mapas de bits estão em estruturas de dados internas do núcleo. Eles não 
precisam ser copiados para serem preservados. Se o atendimento a notificação deve ser adiado, 
isso pode ser sinalizado com um único bit e quando, posteriormente, o destinatário fizer a ope- 
ração de receive, é possível reconstruir o conteúdo da mensagem com base nas informações 
armazenadas. Para o destinatário, a origem da notificação também indica se a mensagem con- 
tém informações adicionais ou não e, se tiver como elas devem ser interpretadas. 

Existem algumas outras primitivas relacionadas à comunicação entre processos, as 
quais serão mencionadas em uma seção posterior. Elas são menos importantes do que send, 
receive, sendrec e notify. 
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2.5.4 Escalonamento de processos no MINIX 3 


O sistema de interrupções é o que mantém um sistema operacional multiprogramado em 
funcionamento. Os processos são bloqueados quando fazem requisições de E/S, permitindo 
que outros processos sejam executados. Quando a operação de E/S é finalizada, o processo 
em execução corrente é interrompido pelo disco, pelo teclado ou por outro hardware. O reló- 
gio também gera interrupções, utilizadas para garantir que um processo de usuário que está 
em execução, e que não solicita requisições de E/S entrada, libere a CPU para dar a outros 
processos a chance de executar. É tarefa da camada inferior do MINIX 3 ocultar essas inter- 
rupções, transformando-as em mensagens. No que diz respeito aos processos, quando um 
dispositivo de E/S completa uma operação, ele envia uma mensagem para algum processo, 
despertando-o e tornando-o apto a executar. 

As interrupções também são geradas por software, no caso em que elas são frequente- 
mente chamadas de traps. As operações send e receive que descrevemos anteriormente são 
transformadas pela biblioteca de sistema em instruções de interrupção de software, as quais 
têm exatamente o mesmo efeito das interrupções geradas pelo hardware — o processo que 
executa uma interrupção de software é bloqueado imediatamente e o núcleo é ativado para 
tratar a interrupção. Os programas de usuário não fazem referência direta a send ou receive, 
mas sempre que uma das chamadas de sistema listadas na Figura 1-9 for ativada, diretamente 
ou por meio de uma rotina de biblioteca, sendrec é usada internamente e também gera uma 
interrupção de software. 

Sempre que um processo é interrompido, seja por um dispositivo de E/S convencional 
ou pelo relógio ou devido à execução de uma instrução de interrupção de software, há uma 
ocasião para determinar qual processo merece a oportunidade de executar. Naturalmente, isso 
também deve ser feito quando um processo termina, mas em um sistema como o MINIX 3 as 
interrupções devidas às operações de E/S, ao relógio ou à passagem de mensagens ocorrem 
mais fregiientemente do que o término de um processo. 

O escalonador do MINIX 3 utiliza um sistema de filas de múltiplos níveis. São defini- 
das 16 filas, embora seja fácil modificá-lo para usar mais ou menos filas. A fila de prioridade 
mais baixa é usada apenas pelo processo IDLE, que é executado quando não há mais nada 
para fazer. Por padrão, os processos de usuário começam em uma fila vários níveis acima da 
mais baixa. 

Os servidores normalmente são postos em filas com prioridades mais altas do que as 
permitidas para os processos de usuário, os drivers em filas com prioridades mais altas do 
que as dos servidores e as tarefas de relógio e de sistema na fila de mais alta prioridade. 
Provavelmente, nem todas as 16 filas disponíveis serão usadas em dado momento. Os pro- 
cessos são iniciados em apenas algumas delas. Um processo pode ser movido para uma fila 
de prioridade diferente pelo sistema ou (dentro de certos limites) por um usuário que ative 
o comando nice. Os níveis extras estão disponíveis para experiências e, à medida que mais 
drivers são adicionados no MINIX 3, as configurações padrões podem ser ajustadas para o 
melhor desempenho. Por exemplo, se quiséssemos adicionar um servidor para fluxo de áudio 
ou vídeo digital em rede, esse servidor poderia receber uma prioridade inicial mais alta do 
que os servidores correntes ou a prioridade inicial de um servidor ou de um driver poderia ser 
reduzida para o novo servidor obter um desempenho melhor. 

Além da prioridade, determinada pela fila em que um processo é posto, outro mecanis- 
mo é usado para dar a alguns processos uma vantagem sobre outros. O quantum, o intervalo 
de tempo permitido antes que um processo sofra preempção, não é o mesmo para todos os 
processos. Os processos de usuário têm um quantum relativamente baixo. Os drivers e ser- 
vidores normalmente devem ser executados até serem bloqueados. Entretanto, como uma 
garantia contra defeitos, eles se tornam passíveis de preempção, mas recebem um quantum 


130 


SISTEMAS OPERACIONAIS 


grande. Eles podem ser executados por um grande número de tiques de relógio, porém finito, 
mas se usarem seu quantum inteiro serão preemptados para não monopolizarem o sistema. 
Nesse caso, o processo com tempo (quantum) esgotado é considerado pronto e é colocado no 
final de sua fila. Entretanto, se um processo que utilizou seu quantum inteiro for o último a 
ser executado, isso será considerado um sinal de que ele pode estar preso em um laço e impe- 
dindo a execução de outros processos com prioridade mais baixa. Nesse caso, sua prioridade 
pode ser diminuída, sendo colocado no final de uma fila de prioridade menor. Se o processo 
esgotar seu tempo novamente e outro processo ainda não for capaz de executar, sua priorida- 
de será diminuída outra vez. Finalmente, algo deverá ter uma chance de executar. 

Um processo cuja prioridade foi diminuída pode merecer estar de volta em uma fila de 
prioridade mais alta. Se um processo usar todo o seu quantum, mas não estiver impedindo 
que outros sejam executados, ele será promovido a uma fila de prioridade mais alta, até a má- 
xima prioridade permitida para ele. Tal processo aparentemente precisa de seu quantum, mas 
não está sendo desatencioso com os outros. 

Caso contrário, os processos têm sua execução programada usando um esquema round- 
robin ligeiramente modificado. Se um processo não tiver usado seu quantum inteiro quando 
deixar de executar, isso significará que ele está bloqueado esperando, por exemplo, por uma 
operação de E/S, e quando se tornar pronto novamente ele será colocado no início da fila, mas 
apenas com a parte restante de seu quantum anterior. Isso se destina a dar aos processos de 
usuário uma resposta rápida à E/S. Já o processo que deixou de executar porque utilizou seu 
quantum inteiro é colocado no final da fila, como em um round-robin puro. 

Com as tarefas normalmente tendo a prioridade mais alta, os drivers em seguida, os ser- 
vidores abaixo dos drivers e os processos de usuário por último, um processo de usuário não 
será executado a menos que todos os processos de sistema não tenham nada para fazer e, um 
processo de sistema não pode ser impedido de executar por um processo de usuário. 

Ao selecionar um processo para executar, o escalonador verifica se existem processos 
enfileirados na fila de prioridade mais alta. Se um ou mais processos estiverem prontos, o 
primeiro da fila será executado. Se nenhum processo estiver pronto, a fila de menor prioridade 
seguinte será testada de modo semelhante e assim por diante. Como os drivers respondem 
às requisições dos servidores e estes respondem às requisições dos processos de usuário, os 
processos de alta prioridade terminarão por concluir o trabalho solicitado a eles. Não tendo 
mais nada para executar, esses processos serão bloqueados dando a oportunidade para que 
os processos de usuário tenham a sua vez de serem executados e façam mais requisições. Se 
nenhum processo estiver pronto, o processo especial IDLE é escolhido para executar. Isso põe 
a CPU em um modo de baixa energia até que ocorra a próxima interrupção. 

A cada tique de relógio é feita uma verificação para ver se o processo corrente foi exe- 
cutado por mais tempo do que o quantum a si atribuído. Se foi, o escalonador o colocará no 
final de sua fila (o que pode exigir não fazer nada, caso ele esteja sozinho na fila). Então, o 
próximo processo a ser executado é selecionado, conforme descrito anteriormente. Somente 
se não houver processos nas filas de prioridade mais alta e, se o processo anterior estiver so- 
zinho em sua fila, é que ele poderá ser executado outra vez, imediatamente. Caso contrário, 
o processo que estiver no início da fila não-vazia de prioridade mais alta será executado em 
seguida. Os drivers e servidores essenciais recebem um quanta tão grande que normalmente 
nunca são preemptados por causa do tempo. Mas se algo der errado, sua prioridade poderá ser 
diminuída temporariamente para evitar a parada total do sistema. Caso isso aconteça com um 
servidor essencial, provavelmente, nada de útil poderá ser feito, mas será possível desligar o 
sistema normalmente, evitando a perda de dados e possivelmente coletando informações que 
podem ajudar na depuração do problema. 
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2.6 IMPLEMENTAÇÃO DE PROCESSOS NO MINIX 3 


2.6.1 


Agora, estamos chegando mais perto do código real; portanto, são necessárias algumas pa- 
lavras sobre a notação que utilizaremos. Os termos procedimento, função e rotina serão uti- 
lizados indistintamente. Os nomes de variáveis, procedimentos e arquivos serão escritos em 
itálico, como em rw flag. Quando uma variável, procedimento, ou nome de arquivo iniciar 
uma frase, será escrito com a primeira letra maiúscula, mas os nomes reais começam com 
letras minúsculas. Existem algumas exceções, as tarefas que são compiladas no núcleo, são 
identificadas por nomes com todas as letras maiúsculas, como em CLOCK, SYSTEM e IDLE. 
As chamadas de sistema estarão em fonte Helvetica minúscula; por exemplo, read. 

O livro e o software, que estão continuamente evoluindo, não foram para o prelo no 
mesmo dia; portanto, pode haver pequenas discrepâncias entre as referências ao código, à lis- 
tagem impressa e à versão do CD-ROM. Essas diferenças, porém, geralmente só afetam uma 
ou duas linhas. O código-fonte impresso no livro também foi simplificado, omitindo o código 
utilizado para compilar opções que não são discutidas no livro. A versão completa está no 
CD-ROM. O site web do MINIX 3 (wuw.minix3.org) tem a versão corrente, que apresenta 
novos recursos, software adicional e documentação. 


Organização do código-fonte do MINIX 3 


A implementação do MINIX 3 descrita neste livro serve para uma máquina tipo IBM PC 
com um chip de processador avançado (por exemplo, 80386, 80486, Pentium, Pentium Pro, 
I, MI, 4, M ou D) que utiliza palavras de 32 bits. Vamos nos referir a todos eles como proces- 
sadores Intel de 32 bits. O caminho completo para o código-fonte em linguagem C, em uma 
plataforma baseada em processador Intel padrão, é /usr/src/ (uma “/” inicial em um nome de 
caminho indica que ele se refere a um diretório). A árvore do diretório fonte para outras plata- 
formas pode estar em um local diferente. Neste livro, os arquivos de código-fonte do MINIX 
3 serão referenciados usando-se um caminho que começa com o diretório superior src/. Um 
subdiretório importante da árvore do diretório fonte é src/include/, onde está localizada a có- 
pia-mestra dos arquivos de cabeçalhos (header files) em C. Vamos nos referir a esse diretório 
como include”. 

Cada diretório na árvore do diretório fonte contém um arquivo chamado Makefile que 
controla a operação do utilitário make padrão do UNIX. O arquivo Makefile controla a com- 
pilação dos arquivos em seu diretório e também pode orientar a compilação de arquivos em 
um ou mais subdiretórios. A operação de make é complexa e uma descrição completa está 
fora dos objetivos desta seção, mas ela pode ser resumida dizendo-se que make gerencia a 
compilação eficiente de programas que envolvem vários arquivos-fonte. Make garante que 
todos os arquivos necessários sejam compilados. Ele testa módulos previamente compilados 
para ver se estão atualizados e recompila todos aqueles cujos arquivos-fonte foram modifi- 
cados desde a compilação anterior. Isso economiza tempo, evitando que a recompilação de 
arquivos que não precisam. Finalmente, make controla a combinação de módulos compilados 
separadamente em um programa executável e também pode gerenciar a instalação do progra- 
ma completo. 

Toda a árvore src/(ou parte dela) pode ser reposicionada, pois o arquivo Makefile em 
cada diretório fonte usa um caminho relativo para diretórios fontes em C. Por exemplo, talvez 
você queira ter o diretório fonte na raiz do sistema de arquivos, /src/, para uma compilação 
mais rápida, se essa raiz for um disco em RAM. Se você estiver desenvolvendo uma versão 
especial de teste, você poderá fazer uma cópia de src/ com outro nome. 

O caminho para os arquivos de cabeçalho do C é um caso especial. Durante a compila- 
ção, todo arquivo Makefile espera encontrar arquivos de cabeçalhos em /usr/include/ (ou no 
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caminho equivalente, em uma plataforma que não seja Intel). Entretanto, src/tools/Makefile, 
usado para recompilar o sistema, espera encontrar uma cópia mestra dos arquivos de cabeça- 
lhos em /usr/src/include (sistemas desenvolvidos para Intel). Contudo, antes de recompilar 
o sistema, a árvore de diretório /usr/include/ inteira é excluída e /usr/src/include/ é copiado 
em /usr/include/. Isso foi feito para tornar possível manter em um só lugar todos os arquivos 
necessários ao desenvolvimento do MINIX 3. Isso também torna fácil manter várias cópias 
inteiras das árvores de diretórios fontes e dos arquivos de cabeçalhos para experimentar dife- 
rentes configurações do sistema MINIX 3. Entretanto, se quiser editar um arquivo de cabeça- 
lho como parte de uma experiência assim, você deve editar a cópia no diretório src/include e 
não a que está em /usr/include/. 

Este é um bom lugar para mostrar aos iniciantes na linguagem C como os nomes de 
arquivo são referenciados em uma instrução include. Todo compilador C tem um diretório 
padrão onde procura os arquivos de cabeçalhos para realizar sua inclusão nos arquivos a 
serem compilados. Frequentemente, ele é /usr/include/. Quando o nome de um arquivo a ser 
incluído é posto entre os símbolos de menor e maior (“< ... >”), o compilador procura o arqui- 
vo no diretório padrão ou em um subdiretório especificado; por exemplo, 


Hinclude <nome de arquivo> 


inclui um arquivo de /usr/includev/. 

Muitos programas também exigem definições em arquivos de cabeçalhos locais que 
não se destinam ao compartilhamento em todo o sistema. Tal arquivo de cabeçalho pode ter 
o mesmo nome e substituir ou complementar um arquivo de cabeçalho padrão. Quando o 
nome é posto entre caracteres de aspas normais (“” ...” ”), o arquivo é procurado primeiro no 
mesmo diretório que o arquivo fonte (ou em um subdiretório especificado) e, então, se não for 


encontrado lá, no diretório padrão. Assim, 
Hinclude “nome de arquivo” 


lê um arquivo local. 
O diretório include/ contém diversos arquivos de cabeçalho padrão do POSIX. Além 
disso, ele tem três subdiretórios: 


sys/ — arquivos de cabeçalho adicionais do POSIX. 
minix/  — arquivos de cabeçalho utilizados pelo sistema operacional MINIX 3. 
ibm/ — arquivos de cabeçalho com definições específicas do IBM PC. 


Para suportar extensões do MINIX 3 e de programas executados nesse ambiente, outros 
arquivos e subdiretórios também estão presentes em include/, conforme fornecido no CD- 
ROM ou no site web do MINIX 3. Por exemplo, include/arpa/ e o diretório include/net/ e 
seu subdiretório include/net/gen/ suportam extensões de rede. Eles não são necessários para 
compilar o sistema MINIX 3 básico e os arquivos desses diretórios não estão listados no 
Apêndice B. 

Além de src/include/, o diretório src/ contêm três outros subdiretórios importantes com 
código-fonte do sistema operacional: 


kernel/ — camada 1 (escalonador, mensagens, tarefas de relógio e de sistema). 
drivers/ — camada 2 (drivers de dispositivo para disco, console, impressora etc.). 


servers/ — camada 3 (gerenciador de processos, sistema de arquivos, outros servidores). 


CAPÍTULO 2 e PROCESSOS 133 


Três outros diretórios de código-fonte não foram impressos nem discutidos neste texto, 
mas são fundamentais para produzir um sistema funcional: 


src/lib/ — código-fonte das funções de biblioteca (por exemplo, open, read). 
src/tools/ — Makefile e scripts para construir o sistema MINIX 3. 


src/boot/ — código para inicializar e instalar o MINIX 3. 


A distribuição padrão do MINIX 3 inclui muitos arquivos-fonte adicionais, não discuti- 
dos neste texto. Além do código-fonte do gerenciador de processos e do sistema de arquivos, 
o diretório src/servers/ contém o código-fonte do programa init e do servidor de reencarnação, 
rs, ambos partes fundamentais de um sistema MINIX 3 funcional. O código-fonte do servidor 
de rede está em src/servers/inet/. Src/drivers/ têm os códigos-fonte de drivers de dispositivos 
não discutidos neste texto, incluindo drivers de disco alternativos, placas de som e adaptado- 
res de rede. Como o MINIX 3 é um sistema operacional experimental, destinado a ser modi- 
ficado, existe um diretório src/test/ com programas projetados para testar completamente um 
sistema MINIX 3 recentemente compilado. É claro que um sistema operacional existe para 
suportar comandos (programas) que serão executados nele; portanto, há um diretório grande, 
o src/commands/, que possui o código-fonte dos programas utilitários (por exemplo, cat, cp, 
date, ls, pwd e mais de 200 outros). Alguns dos principais aplicativos de código-fonte aberto 
desenvolvidos originalmente pelos projetos GNU e BSD também estão aqui. 

A versão do livro do MINIX 3 é configurada com muitas das partes opcionais omitidas 
(acredite: não conseguimos pôr tudo em apenas um livro e nem em nossa cabeça, em um 
curso de duração de um semestre). A versão do livro é compilada usando arquivos Makefile 
modificados que não fazem referência a arquivos desnecessários. (Um arquivo Makefile pa- 
drão exige que arquivos de componentes opcionais estejam presentes, mesmo que não sejam 
compilados.) Omitir esses arquivos e as instruções condicionais que os selecionam torna a 
leitura do código mais fácil. 

Por conveniência, vamos nos referir simplesmente aos nomes dos arquivos quando, a 
partir do contexto, estiver claro qual é o seu caminho completo. Deve-se notar, entretanto, que 
alguns nomes de arquivo aparecem em mais de um diretório. Por exemplo, existem vários ar- 
quivos chamados const.h. Src/kernel /const.h define as constantes usadas no núcleo, enquanto 
src/servers/pm/const.h define as constantes usadas pelo gerenciador de processos, etc. 

Os arquivos de um diretório particular serão discutidos juntos; portanto, não deverá ha- 
ver nenhuma confusão. Os arquivos estão relacionados no Apêndice B na ordem em que são 
discutidos no texto, para facilitar o acompanhamento. Ter dois marcadores de página pode ser 
útil neste ponto, para que você possa alternar entre o texto e a listagem. Para manter razoável 
o tamanho da listagem, não foi impresso o código de cada arquivo. De modo geral, as funções 
descritas em detalhes no texto, estão listadas no Apêndice B; as que são apenas mencionadas 
de passagem, não estão listadas, mas o código-fonte completo está no CD-ROM e no site 
web, que contêm também um índice para funções, definições e variáveis globais presentes no 
código-fonte. 

O Apêndice C contém uma lista em ordem alfabética de todos os arquivos descritos 
no Apêndice B, divididos em seções para arquivos de cabeçalho, drivers, núcleo, sistema de 
arquivos e gerenciador de processos. Esse apêndice e os índices do site web e do CD-ROM 
fazem referência aos elementos listados através do número da linha no código-fonte. 

O código da camada 1 está contido no diretório src/kernel/. Os arquivos desse diretório 
dão suporte para o controle de processos, a camada mais baixa da estrutura do MINIX 3 que 
vimos na Figura 2-29. Essa camada inclui funções que tratam da inicialização do sistema, de 
interrupções, da passagem de mensagens e do escalonamento de processos. Dois módulos 
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diferentes, postos no mesmo arquivo binário, implementam essas funcionalidades, mas eles 
são executados como processos independentes. São eles: a tarefa de sistema, que fornece uma 
interface entre serviços do núcleo e processos nas camadas mais altas, e a tarefa de relógio, 
que fornece sinais de temporização para o núcleo. No Capítulo 3, veremos os arquivos de 
vários outros subdiretórios de src/drivers/ que suportam diversos drivers de dispositivo, a 
segunda camada na Figura 2-29. Em seguida, no Capítulo 4, examinaremos os arquivos do 
gerenciador de processos presentes em src/servers/pm/. Finalmente, no Capítulo 5, estudare- 
mos o sistema de arquivos, cujos arquivos-fonte estão localizados em src/servers/fs/. 


Compilando e executando o MINIX 3 


Para compilar o MINIX 3, execute make em src/tools/. Existem várias opções, para instalar o 
MINIX 3. Para ver as possibilidades, execute make sem nenhum argumento. O método mais 
simples é make image. 

Quando make image é executado, uma nova cópia dos arquivos de cabeçalhos em src/ 
include/ é feita em /usr/include/. Então, os arquivos de código-fonte em src/kernel/ e em 
vários subdiretórios de src/servers/ e src/drivers/ são compilados gerando arquivos-objeto. 
Todos os arquivos-objeto em src/kernel/ são ligados para formar um único programa execu- 
tável, o núcleo. Os arquivos-objeto em src/servers/pm/ também são ligados para formar um 
único programa executável, o pm (process manager) e os arquivos-objeto em src/servers/fs/ 
formam o fs (file system) Os programas adicionais listados como parte da imagem de boot 
na Figura 2-30 também são compilados e ligados em seus próprios diretórios. Isso inclui 
rs (reincarnation server) e init nos subdiretórios de src/servers/, e memory/, log/ e tty/ nos 
subdiretórios de src/drivers/. O componente designado como driver na Figura 2-30 pode ser 
um de vários drivers de disco; discutiremos aqui um sistema MINIX 3 configurado para ini- 
cializar a partir de um disco rígido usando o driver at wini padrão, o qual será compilado em 
src/drivers/at  wini/. Outros drivers podem ser adicionados, mas a maioria não precisa ser 
compilada na imagem de boot. O mesmo vale para o suporte à rede; a compilação do sistema 
MINIX 3 básico é a mesma, seja usada a rede ou não. 

Para instalar um sistema MINIX 3 funcional, capaz de ser inicializado, um programa 
chamado installboot (cujo código-fonte está em src/boot/) adiciona nomes nos programas 
kernel, pm, fs, init e nos outros componentes da imagem de boot, ajusta cada um deles de 
modo que seu tamanho seja um múltiplo do tamanho do setor do disco (para tornar mais 
fácil carregar as partes independentemente) e os concatena em um único arquivo. Esse novo 
arquivo é a imagem de boot e pode ser copiado no diretório /boot/, no diretório /boot/image/ 
de um disquete ou na partição de um disco rígido. Posteriormente, o programa monitor de 
inicialização pode carregar essa imagem e transferir o controle para o sistema operacional. 

A Figura 2-31 mostra o layout da memória depois que os programas são carregados. O 
núcleo em si é carregado na parte baixa da memória, todas as outras partes da imagem de boot 
são carregadas acima de 1 MB. Quando os programas de usuário forem executados, a memó- 
ria disponível acima do núcleo será usada primeiro. Se um novo programa não couber mais 
nesse espaço, ele será carregado no intervalo da memória alta, acima de init. Os detalhes, é 
claro, dependem da configuração do sistema. O exemplo mostrado na figura é de um sistema 
de arquivos do MINIX 3 configurado com uma cache que pode conter 512 blocos de disco 
de 4 KB. Esse é um valor modesto; recomenda-se usar mais, se houver memória adequada 
disponível. Por outro lado, se o tamanho da cache fosse drasticamente reduzido, seria possí- 
vel fazer o sistema inteiro caber em menos de 640K de memória, com espaço também para 
alguns poucos processos de usuário. 
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Limite de memória 


Memória disponível 
para programas 
de usuário 


RR - 3549K 
src/servers/init/init 
À ni o 3 : 3537K 
src/drivers/at wini/at wini 
a - 3489K 
src/drivers/log/log Driver de log 
: a E 3416K 
src/drivers/memory/memory Epa 
sredrivers ty 


3375K 
src/servers/rs/rs Servidor de reencarnação , 
3236K (Depende do número 


de buffers incluídos 


src/servers/fs/fs Sistema de arquivos no sistema de arquivos) 


1093K 
src/servers/pm/pm Gerenciador de processos 


1024K 
ROM e memória de 
adaptador de E/S 

(não disponível 

para o MINIX 3) 


[Monitor de inicialização] 640K 
onitor de inicialização 
£ 590K 
Memória disponível 
para programas 
de usuário 
55K 


Tarefa de sistema 

src/kernel/kernel 
núcleo 

[Usada pela BIOS] 


2K Início do núcleo 
1K 


[Vetores de interrupção] 


0 


Figura 2-31 Layout da memória após o MINIX 3 ter sido carregado do disco para a memó- 
ria. O núcleo, os servidores e os drivers são programas compilados e ligados independente- 
mente (nomes listados à esquerda). Os tamanhos são aproximados e não estão em escala. 


É importante saber que o MINIX 3 consiste em vários programas totalmente indepen- 
dentes que se comunicam apenas passando mensagens. Uma função chamada panic no di- 
retório src/servers/fs/ não gera conflito com uma função chamada panic em src/servers/pm/, 
pois, em última análise, elas pertencem a arquivos executáveis diferentes. As únicas funções 
que as três partes do sistema operacional têm em comum são algumas das rotinas de biblio- 
teca em src/lib/. Essa estrutura modular torna muito fácil modificar, digamos, o sistema de 
arquivos, sem que essas alterações afetem o gerenciador de processos. Ela também torna 
simples remover o sistema de arquivos inteiro e colocá-lo em uma máquina diferente, com 
o servidor de arquivos comunicando-se com máquinas de usuário por meio de mensagens 
enviadas via rede. 


136 


SISTEMAS OPERACIONAIS 


2.6.3 


Como outro exemplo da modularidade do MINIX 3, temos a adição de suporte à rede, 
que não faz absolutamente nenhuma diferença para o gerenciador de processos, para o sis- 
tema de arquivos ou para o núcleo. Um driver Ethernet e o servidor inet podem ser ativados 
após a imagem de boot (boot image) ser carregada; eles apareceriam na Figura 2-30 com os 
processos iniciados por /etc/rc e seriam carregados em uma das regiões de memória dispo- 
nível para programas de usuário da Figura 2-31. Um sistema MINIX 3 com suporte à rede 
ativado pode ser usado como um terminal remoto, como um servidor de ftp ou como servidor 
web. Se você quisesse permitir logins recebidos pela rede no sistema MINIX 3 seria necessá- 
rio modificar algumas partes conforme descrito no texto: o tty e o driver de console precisa- 
riam ser recompilados com pseudoterminais configurados para permitir logins remotos. 


Os arquivos de cabeçalho comuns 


O diretório include/ e seus subdiretórios contêm uma coleção de arquivos definindo constan- 
tes, macros e tipos. O padrão POSIX exige muitas dessas definições e especifica em quais 
arquivos do diretório principal include/ e seu subdiretório include/sys/ será encontrada cada 
definição necessária. Os arquivos desses diretórios são arquivos de cabeçalho ou de inclu- 
são (include files), identificados pelo sufixo .h (de header) e utilizados por meio de diretivas 
finclude em arquivos-fonte da linguagem C. Essas diretivas são um recurso interno da lingua- 
gem C. Os arquivos include tornam mais fácil a manutenção de um sistema grande. 

Os arquivos de cabeçalho comumente necessários para compilar programas de usuário 
estão localizados principalmente em include/, enquanto include/sys/ é tradicionalmente em- 
pregado para armazenar os arquivos usados para compilar programas e utilitários de sistema. 
A distinção não é tão importante, e uma compilação típica, seja de um programa de usuário, 
ou de parte do sistema operacional, incluirá arquivos desses dois diretórios. Discutiremos 
aqui os arquivos necessários para compilar o sistema MINIX 3 padrão, tratando primeiro 
daqueles que estão em include/ e, depois, daqueles que estão em include/sys/. Na próxima 
seção, discutiremos os arquivos dos diretórios include/minix/ e include/ibm/, os quais, con- 
forme os nomes de diretório indicam, são exclusivos do MINIX 3, e sua implementação em 
computadores do tipo IBM (na verdade, do tipo Intel). 

Os primeiros arquivos de cabeçalhos a serem considerados são verdadeiramente de pro- 
pósito geral, tanto que não são referenciados diretamente por nenhum dos arquivos-fonte da 
linguagem C do sistema MINIX 3. Em vez disso, eles são incluídos em outros arquivos de 
cabeçalhos. Cada componente importante do MINIX 3 tem um arquivo de cabeçalho mes- 
tre, como src/kernel/kernel.h, src/servers/pm/pm.h e src/servers/fs/fs.h. Eles são incluídos em 
toda compilação desses componentes. O código-fonte de cada um dos drivers de dispositivo 
inclui um arquivo bastante parecido, src/drivers/drivers.h. Cada arquivo de cabeçalho mestre 
é personalizado de acordo com as necessidades da parte correspondente do sistema MINIX 
3, mas cada um começa com uma seção como a que aparece na Figura 2-32 e inclui a maioria 
dos arquivos lá mostrados. Os arquivos de inclusão mestres serão discutidos novamente em 
outras seções do livro. Esta prévia serve para enfatizar que arquivos de cabeçalhos de vários 
diretórios são utilizados juntos. Nesta seção e na próxima, mencionaremos cada um dos ar- 
quivos referenciados na Figura 2-32. 

Vamos começar com o primeiro arquivo em include/, ansi.h (linha 0000). Esse é o se- 
gundo arquivo processado quando qualquer parte do sistema MINIX 3 é compilada; somente 
include/minix/config.h é processado antes. O propósito de ansi.h é testar se o compilador 
satisfaz os requisitos do Standard C, conforme definido pela International Organization for 
Standards. O Standard C frequentemente também é chamado de ANSI C, pois o padrão foi 
desenvolvido originalmente pelo American National Standards Institute, antes de obter reco- 
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Hinclude <minix/config.h> /* DEVE ser o primeiro */ 
Hinclude <ansi.h> /* DEVE ser o segundo */ 
Hinclude <limits.h> 

Hinclude <errno.h> 

Hinclude <sys/types.h> 

Hinclude <minix/const.h> 

Hinclude <minix/type.h> 

tinclude <minix/syslib.h> 

Hinclude “const.h” 


Figura 2-32 Parte de um arquivo de cabeçalho mestre que garante a inclusão dos demais 
arquivos de cabeçalhos necessários a todos os arquivos fonte. Note que são referenciados dois 
arquivos const.h, um da árvore include/ e um do diretório local. 


nhecimento internacional. Um compilador Standard C define várias macros que podem ser 
testadas na compilação de programas. STDC é uma dessas macros e é definida por um 
compilador padrão para ter o valor igual a 1, exatamente como se o pré-processador C tivesse 
lido uma linha como 


#define STDC 1 


O compilador distribuído com as versões correntes do MINIX 3 é compatível com o 
Standard C, mas as versões mais antigas do MINIX foram desenvolvidas antes da adoção do 
padrão e ainda é possível compilar o MINIX 3 com um compilador C clássico (Kernighan & 
Ritchie). A intenção é que o MINIX 3 seja fácil de portar para novas máquinas e permitir o 
uso de compiladores mais antigos faz parte disso. Nas linhas 0023 a 0025, a diretiva 


tidefine ANSI 


é processada se um compilador Standard C estiver em uso. Ansi.h define várias macros de 
diferentes maneiras, dependendo de a macro  ANSI ser definida ou não. Esse é um exemplo 
de macro de teste de recurso. 

Outra macro de teste de recurso definida aqui é POSIX SOURCE (linha 0065). Isso 
é exigido pelo POSIX. Aqui, garantimos sua definição para o caso de serem definidas outras 
macros que impliquem na compatibilidade com o padrão POSIX. 

Ao compilar um programa em C, os tipos de dados dos argumentos e dos valores retor- 
nados das funções devem ser conhecidos antes que o código que referencia tais dados possa 
ser gerado. Em um sistema complexo, é difícil ordenar as definições de função para atender a 
esse requisito; portanto, a linguagem C permite o uso de protótipos de função (prototypes) 
para declarar os tipos dos argumentos e do valor de retorno de uma função, antes que ela seja 
definida. A macro mais importante em ansi.h é PROTOTYPE. Essa macro permite escrever 
protótipos de função na forma 


- PROTOTYPE (tipo-de-retorno nome-da-função, (tipo-de-argumento argumento, ...)) 
e ter isso transformado pelo pré-processador C em 

tipo-de-retorno nome-da-função (tipo-do-argumento argumento, ...) 
se o compilador for um Standard C da ANSI, ou em 

tipo-de-retorno nome-da-função () 


se o compilador for antigo (isto é, Kernighan & Ritchie). 
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Antes de deixarmos ansi.h, vamos mencionar mais um recurso. O arquivo inteiro (exce- 
to os comentários iniciais) está incluído entre as linhas 


Hifndef ANSIL H 


#endif /* _ANSI_H */ 


Na linha imediatamente após #ifndef, _ANSI_H em si é definido. Um arquivo de cabeçalho 
deve ser incluído apenas uma vez em uma compilação; essa construção garante que o con- 
teúdo do arquivo seja ignorado, caso seja incluído várias vezes. Veremos essa técnica utiliza- 
da em todos os arquivos de cabeçalho do diretório include/. 

Dois pontos sobre isso merecem ser mencionados. Primeiramente, em todas as seqüên- 
cias de arquivos #ifndef ... #define nos diretórios de arquivos de cabeçalho mestres, o nome 
do arquivo é precedido por um sublinhado. Pode existir outro cabeçalho com o mesmo nome 
dentro dos diretórios de código-fonte em C e o mesmo mecanismo será usado lá, mas a mesma 
sequência de sublinhados não deverá ser usada. Assim, a inclusão de um arquivo de cabeçalho 
do diretório mestre não impedirá o processamento de outro arquivo de cabeçalho com o mes- 
mo nome em um diretório local. Segundo, note que o comentário /* _ANSI_H */, após a ins- 
trução #ifndef, não é obrigatório. Tais comentários podem ser úteis para monitorar seções de 
Hifndef ... #endif e #ifdef ... #endif aninhadas. Entretanto, é preciso cuidado ao se escrever tais 
comentários: se estiverem incorretos eles serão piores do que não ter nenhum comentário. 

O segundo arquivo em include/ que é incluído indiretamente na maioria dos arquivos- 
fonte do MINIX 3 é o cabeçalho limits.h (linha 0100). Esse arquivo define vários tamanhos 
básicos, sejam dos tipos de linguagem, como o número de bits em um número inteiro, sejam 
os limites do sistema operacional, como o comprimento do nome de um arquivo. 

Note que, por conveniência, a numeração de linha no Apêndice B pula para o próximo 
múltiplo de 100 quando um novo arquivo é listado. Assim, não espere que ansi.h contenha 
100 linhas (de 00000 a 00099). Desse modo, pequenas alterações em um arquivo não afe- 
tarão (provavelmente) os arquivos subsequentes em uma listagem revisada. Note também 
que, quando é encontrado um novo arquivo na listagem, existe um cabeçalho de três linhas 
especial, consistindo em uma segiiência de sinais de adição (+), no nome de arquivo e em 
outra sequência de sinais de adição (sem numeração de linha). Um exemplo desse cabeçalho 
aparece entre as linhas 00068 e 00100. 

Errno.h (linha 0200), também é incluído pela maioria dos arquivos de cabeçalho mes- 
tres. Ele contém os números de erro retornados para programas de usuário na variável global 
errno, quando uma chamada de sistema falha. Errno também é utilizado para identificar 
alguns erros internos, como a tentativa de enviar uma mensagem para uma tarefa inexistente. 
Internamente, seria ineficiente examinar uma variável global após uma chamada para uma 
função que poderia gerar um erro, mas as funções frequentemente devem retornar outros 
valores inteiros, por exemplo, o número de bytes transferidos durante uma operação de E/S. 
A solução do MINIX 3 é retornar números de erro como valores negativos para identificá-los 
como códigos de erro dentro do sistema e depois convertê-los em valores positivos, antes que 
sejam retornados para os programas de usuário. O truque utilizado é que cada código de erro 
é definido em uma linha como 


gdefine EPERM (SIGN 1) 


(linha 0236). O arquivo de cabeçalho mestre de cada parte do sistema operacional define a 
macro SYSTEM, mas SYSTEM não é definida quando um programa de usuário é compila- 
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do. Se. SYSTEM for definida, então SIGN será definida como “—”; caso contrário, receberá 
uma definição nula. 

O próximo grupo de arquivos a serem considerados não é incluído em todos os arqui- 
vos de cabeçalho mestres, mas não obstante são usados em muitos arquivos-fonte em todas 
as partes do sistema MINIX 3. O mais importante é unistd.h (linha 0400). Esse arquivo de 
cabeçalho define muitas constantes, a maioria das quais exigidas pelo POSIX. Além disso, ele 
contém protótipos (prototypes) para muitas funções da linguagem C, incluindo todas aquelas 
utilizadas para acessar chamadas de sistema do MINIX 3. Outro arquivo amplamente utili- 
zado é string.h (linha 0600), que fornece protótipos para várias funções da linguagem C de 
manipulação de strings. O arquivo de cabeçalho signal.h (linha 0700) define os nomes de si- 
nais padrão. Também são definidos vários sinais específicos do MINIX 3, para uso do sistema 
operacional. O fato de as funções dos sistemas operacionais serem tratadas por processos in- 
dependentes, em vez de o serem dentro de um núcleo monolítico, exige alguma comunicação 
de sinal especial entre os componentes do sistema. Signal.h também contém protótipos para 
algumas funções relacionadas com sinais. Conforme veremos mais adiante, o tratamento de 
sinais envolve todas as partes do MINIX 3. 

Fcntl.h (linha 0900) define simbolicamente muitos parâmetros utilizados em operações 
de controle de arquivo. Por exemplo, ele permite utilizar a macro O RDONLY, em vez do 
valor numérico 0, como parâmetro para uma chamada de open. Embora esse arquivo seja re- 
ferenciado principalmente pelo sistema de arquivos, suas definições também são necessárias 
em diversos lugares no núcleo e no gerenciador de processos. 

Conforme veremos quando estudarmos a camada de driver de dispositivo, no Capítulo 
3, o console e a interface de terminal de um sistema operacional são complexos, pois muitos 
tipos diferentes de hardware têm de interagir de maneira padronizada com o sistema opera- 
cional e com programas de usuário. Termios.h (linha 1000) define constantes, macros e protó- 
tipos de função utilizados para controle de dispositivos de E/S tipo terminal. A estrutura mais 
importante é a termios. Ela contém flags para sinalizar vários modos de operação, variáveis 
para configurar velocidades de transmissão de entrada e saída e um array para armazenar 
caracteres especiais (por exemplo, os caracteres INTR e KILL). Essa estrutura é exigida pelo 
POSIX, assim como muitas das macros e dos protótipos de função definidos nesse arquivo. 

Entretanto, apesar de ter sido concebido para ser bastante abrangente, o padrão POSIX 
não fornece tudo que se poderia querer e a última parte do arquivo, da linha 1140 em diante, 
fornece extensões para o POSIX. Algumas delas são de valor óbvio, como as extensões para 
definir taxas de transmissão de dados padrão de 57.600 baud e superiores, e suporte para exi- 
bição de janelas na tela do terminal. O padrão POSIX não proíbe extensões, já que nenhum 
padrão razoável poderia incluir tudo. Mas quando se escreve um programa no ambiente MI- 
NIX 3, destinado a ser portável para outros ambientes, alguma cautela é necessária para evitar 
o uso de definições específicas do MINIX 3. Isso é muito fácil de fazer. Nesse e em outros 
arquivos que definem extensões específicas do MINIX 3, o uso das extensões é controlado 
pela instrução: 


#ifdef . MINIX 


Se a macro MINIX não for definida, o compilador nem mesmo verá as extensões do 
MINIX 3; todas elas serão completamente ignoradas. 

Temporizadores de alarme denominados de cães de guarda (watchdogs) são suportados 
por timers.h (linha 1300), que é incluído no arquivo de cabeçalho mestre do núcleo. Ele de- 
fine um struct timer, assim como protótipos de funções usados para operar em listas de tem- 
porizadores. Na linha 1321 aparece um tipo de dados typedef para tmr func t. Esse tipo de 
dados é um ponteiro para uma função. Seu uso aparece na linha 1332: dentro de uma estrutu- 
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ra timer, usado como um elemento em uma lista de temporizadores, há um campo tmr. func t 
que serve para especificar uma função a ser chamada quando o temporizador expira. 

Mencionaremos mais quatro arquivos do diretório include/ que não estão listados no 
Apêndice B. Stdlib.h define tipos, macros e protótipos de função que provavelmente serão ne- 
cessários na compilação de todos os programas em C, menos os mais simples. Esse é um dos 
arquivos de cabeçalho mais frequentemente usado na compilação de programas de usuário, 
embora dentro do código-fonte do sistema MINIX 3 ele seja referenciado apenas por alguns 
arquivos no núcleo. Stdio.h é conhecido de todos que começaram a aprender a programar em 
C escrevendo o famoso programa “Hello World!”. Dificilmente ele é usado em arquivos de 
sistema, embora, como stdlib.h, seja usado em quase todos os programas de usuário. A.out.h 
define o formato dos arquivos nos quais os programas executáveis são armazenados no disco. 
Uma estrutura exec é definida aqui e as informações presentes nessa estrutura são usadas pelo 
gerenciador de processos para carregar uma nova imagem de programa quando é feita uma 
chamada de exec. Finalmente, stddef.h define algumas macros comumente usadas. 

Agora vamos prosseguir para o subdiretório include/sys/. Como mostrado na Figura 2- 
32, todos os arquivos de cabeçalho mestres das partes principais do sistema MINIX 3 incluem 
sys/types.h (linha 1400), para ser lido imediatamente após a leitura de ansi.h. Sys/types.h 
define muitos tipos de dados utilizados pelo MINIX 3. Os erros que poderiam surgir da má 
interpretação de quais tipos de dados fundamentais são utilizados em uma situação particular 
podem ser evitados utilizando-se as definições fornecidas aqui. A Figura 2-33 mostra o modo 
como os tamanhos (em bits) de alguns tipos definidos nesse arquivo diferem quando compi- 
lados para processadores de 16 bits ou de 32 bits. Note que todos os nomes de tipo terminam 
com “ t”. Isso não é apenas uma convenção; é um requisito do padrão POSIX. Esse é um 
exemplo de sufixo reservado e “ t” não deve ser utilizado como sufixo de qualquer nome 
que não seja um nome de tipo. 


Tipo | MINIX de 16 bits | MINIX de 32 bits 
gid t 8 8 
dev t 16 16 
pid t 16 32 
ino t 16 32 


Figura 2-33 O tamanho, em bits, de alguns tipos em sistemas de 16 e de 32 bits. 


Atualmente, o MINIX 3 é executado de forma nativa em microprocessadores de 32 bits, 
mas processadores de 64 bits serão cada vez mais importantes no futuro. Um tipo que não 
é fornecido pelo hardware pode ser sintetizado, se necessário. Na linha 1471, tipo u64 t é 
definido como struct (U32. t[2]). Esse tipo não é necessário com muita frequência na imple- 
mentação atual, mas ele pode ser útil — por exemplo, todos os dados de disco e de partição 
(deslocamentos e tamanhos) são armazenados como números de 64 bits, permitindo o uso de 
discos muito grandes. 

O MINIX 3 usa muitas definições de tipo que, em última análise, são interpretados 
pelo compilador como um número relativamente pequeno de tipos comuns. Isso se destina 
a ajudar a tornar o código mais legível; por exemplo, uma variável declarada como sendo de 
tipo dev. t é reconhecida como uma variável destinada a conter os números de dispositivo 
principal e secundário que identificam completamente um dispositivo de E/S. Para o compi- 
lador, declarar essa variável como short funcionaria igualmente bem. Outro detalhe a notar 
é que muitos dos tipos definidos aqui são iguais aos tipos correspondentes com a primeira 
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letra maiúscula, por exemplo, dev te Dev t. Para o compilador, todas as variantes com letras 
maiúsculas são equivalentes ao tipo int; elas são fornecidas para serem utilizadas em protóti- 
pos de função que precisam usar tipos compatíveis com o tipo int para suportar compiladores 
K&R. Os comentários presentes no arquivo types.h explicam isso com mais detalhes. 

Um outro item que merece menção é a seção de código condicional que começa com 


#if EM WSIZE == 2 


(linhas 1502 a 1516). Conforme observado anteriormente, a maior parte do código condi- 
cional foi removida do código-fonte discutido no texto. Esse exemplo foi mantido para que 
pudéssemos mostrar uma maneira de usar definições condicionais. A macro usada, EM | 
WSIZE, é outro exemplo de macro de teste de recurso definida pelo compilador. Ela informa 
o tamanho de palavra do sistema de destino, em bytes. A segiiência Hif ... #else ... endif é 
uma maneira de obter algumas definições certas de uma vez por todas, para fazer o código 
subsequente compilar corretamente, seja em um sistema de 16 bits, seja em um sistema de 
32 bits. 

Vários outros arquivos em include/sys/ são amplamente utilizados no sistema MINIX 3. 
O arquivo sys/sigcontext.h (linha 1600) define as estruturas usadas para preservar e restaurar 
a operação normal do sistema, antes e depois da execução de uma rotina de tratamento de 
sinal, e é utilizado tanto no núcleo como no gerenciador de processos. Sys/stat.h (linha 17700) 
define a estrutura que vimos na Figura 1-12, retornada pelas chamadas de sistema stat e fstat, 
assim como os protótipos das funções stat e fstat e outras funções usadas para manipular 
propriedades de arquivos. Ele é referenciado em várias partes do sistema de arquivos e do 
gerenciador de processos. 

Outros arquivos que discutiremos nesta seção não são tão utilizados quanto aqueles 
discutidos anteriormente. Sys/dir.h (linha 1800) define a estrutura de uma entrada de diretório 
do MINIX 3. Ele é diretamente mencionado apenas uma vez, mas essa referência o inclui em 
outro arquivo de cabeçalho que é amplamente usado no sistema de arquivos. Ele é importante 
porque, dentre outras coisas, informa quantos caracteres um nome de arquivo pode conter 
(60). O cabeçalho sys/wait.h (linha 1900) define as macros usadas pelas chamadas de sistema 
wait e waitpid, as quais são implementadas no gerenciador de processos. 

Vários outros arquivos em include/sys/ devem ser mencionados, embora não estejam 
listados no Apêndice B. O MINIX 3 suporta o rastreamento de executáveis e a análise de core 
dumps com um programa depurador, e sys/ptrace.h define as várias operações possíveis com 
a chamada de sistema ptrace. Sys/svrctl.h define as estruturas de dados e macros usadas por 
svrctl, que não é realmente uma chamada de sistema, mas é utilizada como se fosse. Svrctl é 
usado para coordenar processos em nível de servidor quando o sistema inicia. A chamada de 
sistema select permite esperar por entradas provenientes de múltiplos canais — por exemplo, 
pseudo-terminais esperando por conexões de rede. As definições necessárias para essa cha- 
mada estão em sys/select.h. 

Deixamos deliberadamente a discussão de sys/ioctl.h e arquivos relacionados por últi- 
mo, pois eles não podem ser totalmente entendidos sem também examinarmos um arquivo 
do próximo diretório, minix/ioctl.h. A chamada de sistema ioctl é usada por operações de 
controle de dispositivo. O número de dispositivos que podem fazer interface com um sis- 
tema de computador moderno está sempre aumentando. Todos precisam de vários tipos de 
controle. Na verdade, a principal diferença entre o MINIX 3 descrito neste livro e as outras 
versões é que, para os propósitos do livro, descrevemos o MINIX 3 com relativamente poucos 
dispositivos de entrada/saída. Muitos outros podem ser adicionados, como interfaces de rede, 
controladoras SCSI e placas de som. 
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2.6.4 


Para tornar as coisas mais fáceis de administrar, são usados vários arquivos pequenos, 
cada um contendo um grupo de definições. Todos eles são incluídos por sys/ioctl.h (linha 
2000), que funciona de modo semelhante ao arquivo de cabeçalho mestre da Figura 2-32. 
No Apêndice B, listamos apenas um desses arquivos incluídos, sys/ioc disk.h (linha 2100). 
Esse e outros arquivos incluídos por sys ioctl.h estão localizados no diretório include/sys/, 
pois são considerados como parte da interface publicada, significando que um programador 
pode usá-los para escrever qualquer programa a ser executado no ambiente do MINIX 3. En- 
tretanto, todos eles dependem das definições de macro adicionais fornecidas em minix/ioctl.h 
(linha 2200), que é incluído por cada um. Minix/ioctl.h não deve ser usado sozinho na escrita 
de programas e esse é o motivo pelo qual está em include/minix/e não em include/sys/. 

As macros definidas nesses arquivos estabelecem como os vários elementos necessários 
a cada possível função são armazenados em um valor inteiro de 32 bits a ser passado para ioc- 
tl. Por exemplo, os dispositivos de disco precisam de cinco tipos de operações, conforme pode 
ser visto em sys/ioc disk.h, nas linhas 2110 a 2114. O parâmetro alfabético ‘ď’ indica a ioctl 
que a operação é para um dispositivo de disco, um valor inteiro de 3 a 7 codifica a operação 
e o terceiro parâmetro de uma operação de gravação ou leitura indica o tamanho da estrutura 
na qual os dados devem ser passados. Em minix/ioctl.h, as linhas 2225 a 2231 mostram que 
8 bits do código alfabético são deslocados 8 bits para a esquerda, os 13 bits menos signifi- 
cativos do tamanho da estrutura são deslocados 16 bits para a esquerda e, então, a operação 
lógica E é aplicada a eles com o código da operação (que é um valor inteiro numericamente 
pequeno). Outro código, nos 3 bits mais significativos de um número de 32 bits, fornece o 
tipo do valor de retorno. 

Embora isso pareça trabalhoso, isso é feito no momento da compilação e produz uma 
interface muito mais eficiente para a chamada de sistema no momento da execução, pois o 
parâmetro realmente passado é o tipo de dados mais natural para a CPU da máquina hospe- 
deira. Entretanto, isso faz lembrar de um famoso comentário de Ken Thompson, colocado no 
código-fonte de uma versão inicial do UNIX: 


/* Não se espera que você entenda isto */ 


Minix/ioctl.h também contém o protótipo da chamada de sistema ioctl, na linha 2241. 
Em muitos casos, essa chamada não é feita diretamente pelos programadores, pois as funções 
definidas pelo padrão POSIX, cujo protótipo está em include/termios.h, têm substituído o em- 
prego da antiga função de biblioteca ioctl para tratar com terminais, consoles e dispositivos 
semelhantes. Contudo, ela ainda é necessária. Na verdade, as funções POSIX para controle de 
dispositivos de terminal são convertidas em chamadas de sistema ioctl pela biblioteca. 


Arquivo de cabeçalho do MINIX 3 


Os subdiretórios include/minix/ e include/ibm/ contêm arquivos de cabeçalho específicos do 
MINIX 3. Os arquivos em include/minix/ são necessários para uma implementação do MI- 
NIX 3 em qualquer plataforma, embora haja definições alternativas específicas a uma pla- 
taforma dentro de alguns deles. Já discutimos um arquivo aqui, o ioctl.h. Os arquivos em 
include/ibm/ definem estruturas e macros específicas do MINIX 3, quando implementado em 
máquinas tipo IBM. 

Começaremos com o diretório minix/. Na seção anterior, foi visto que config.h (linha 
2300) é incluído nos cabeçalhos mestres de todas as partes do sistema MINIX 3 e, portanto, 
é o primeiro arquivo realmente processado pelo compilador. Em muitas ocasiões, quando 
diferenças no hardware, ou no modo como o sistema operacional destina-se a ser empregado, 
exigem alterações na configuração do MINIX 3, editar esse arquivo e recompilar o sistema 
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é tudo o que precisa ser feito. Sugerimos que, caso você modifique esse arquivo, modifique 
também o comentário na linha 2303 para ajudar a identificar o objetivo das modificações. 

Todos os parâmetros que podem ser configurados pelo usuário estão na primeira parte 
do arquivo, mas alguns desses parâmetros não se destinam a ser editados aqui. A linha 2326 
inclui outro arquivo de cabeçalho, minix/sys config.h, e as definições de alguns parâmetros 
são herdadas desse arquivo. Os programadores acharam que essa era uma boa idéia, pois 
alguns arquivos no sistema precisam das definições básicas presentes em sys config.h, sem 
o restante das que se encontram em config.h. Na verdade, existem muitos nomes em config.h 
que não começam com um sublinhado, os quais provavelmente entrarão em conflito com os 
nomes de utilização comum, como CHIP ou INTEL, passíveis de serem encontrados em soft- 
ware portado de outro sistema operacional para o MINIX 3. Todos os nomes em sys. config.h 
começam com sublinhados para tornar os conflitos menos prováveis. 

MACHINE é, na verdade, configurada como MACHINE IBM PC em sys config.h; 
as linhas 2330 a 2334 listam alternativas para os valores possíveis de MACHINE. As versões 
anteriores do MINIX foram portadas para as plataformas Sun, Atari e MacIntosh, e o código- 
fonte completo contém alternativas para esses hardwares. A maior parte do código-fonte do 
MINIX 3 é independente do tipo de máquina, mas um sistema operacional sempre tem algum 
código dependente do sistema. Além disso, deve ser notado que, como o MINIX 3 é muito 
recente, quando este livro estava sendo escrito ainda faltava acabar de portar o MINIX 3 para 
plataformas que não fossem Intel. 

Outras definições em config.h permitem a personalização para outras necessidades em 
uma instalação particular. Por exemplo, o número de buffers usados pelo sistema de arqui- 
vos para a cache de disco geralmente deve ser o maior possível, mas um número grande de 
buffers exige muita memória. Colocar 128 blocos na cache, conforme configurado na linha 
2345, é considerado o mínimo e é satisfatório apenas para uma instalação do MINIX 3 em 
um sistema com menos de 16 MB de memória RAM; para sistemas com bastante memória, 
um número muito maior pode ser colocado aqui. Se for desejado usar um modem ou uma 
conexão de rede, as definições de NR SR LINES e NR PTYS (linhas 2379 e 2380) devem 
ser aumentadas e o sistema recompilado. A última parte de config.h contém definições que 
são necessárias, mas que não devem ser alteradas. Muitas definições aqui estabelecem apenas 
nomes alternativos para as constantes definidas em sys config.h. 

Sys. config.h (linha 2500) contém definições que provavelmente serão necessárias para 
um programador de sistema; por exemplo, alguém que esteja escrevendo um novo driver de 
dispositivo. Você provavelmente não precisará alterar muito esse arquivo, com a possível 
exceção de NR PROCS (linha 2522). Isso controla o tamanho da tabela de processos. Se 
você quiser usar um sistema MINIX 3 como servidor de rede, com muitos usuários remotos 
ou com muitos processos de servidor sendo executados simultaneamente, talvez precise au- 
mentar essa constante. 

O próximo arquivo é const.h (linha 2600), que ilustra outro uso comum dos arquivos 
de cabeçalho. Aqui, encontramos uma variedade de definições de constantes que provavel- 
mente não serão alteradas ao se compilar um novo núcleo, mas que são usadas em vários 
lugares. A definição delas ajuda a evitar erros que poderiam ser difíceis de rastrear se fossem 
feitas definições inconsistentes em vários lugares. Outros arquivos chamados const.h podem 
ser encontrados em outras partes da árvore do código-fonte do MINIX 3, mas eles têm uso 
mais limitado. Analogamente, as definições utilizadas somente no núcleo são incluídas em 
src/kernel/const.h. As definições utilizadas apenas no sistema de arquivos são incluídas em 
src/servers/fs/const.h. O gerenciador de processos utiliza src/servers/pm/const.h para suas 
definições locais. Apenas as definições usadas em mais de uma parte do sistema MINIX 3 são 
incluídas em include/minix/const.h. 
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Algumas das definições em const.h são dignas de nota. EXTERN é definida como uma 
macro que se expande em extern (linha 2608). As variáveis globais declaradas em arquivos de 
cabeçalho e incluídas em dois ou mais arquivos são declaradas como EXTERN, como em 


EXTERN int who; 
Se a variável fosse declarada apenas como 
int who; 


e incluída em dois ou mais arquivos, alguns ligadores (linkers) reclamariam de uma variável 
com múltipla definição. Além disso, o manual de referência da linguagem C proíbe explicita- 
mente (Kernighan e Ritchie, 1988) essa construção. 

Para evitar esse problema, é necessário fazer a declaração assim: 


extern int who; 


em todos os lugares, exceto um. O uso de EXTERN evita esse problema, porque ela se ex- 
pande em extern em todos os pontos em que const.h é incluída, exceto após uma redefinição 
explícita de EXTERN como uma string nula. Isso é feito em cada parte do MINIX 3, colo- 
cando-se as definições globais em um arquivo especial chamado glo.h (por exemplo, src/ker- 
nel/glo.h), que é incluído indiretamente em cada compilação. Dentro de cada arquivo glo.h 
há uma segiiência 


tifdef TABLE 
tundef EXTERN 
tidefine EXTERN 
#endif 


e nos arquivos table.c de cada parte do MINIX 3 há uma linha 
#define _TABLE 


precedendo a seção #include. Assim, quando os arquivos de cabeçalho são incluídos e ex- 
pandidos como parte da compilação de table.c, extern não é inserida em qualquer lugar (pois 
EXTERN é definida como uma string nula dentro de table.c) e o armazenamento das variáveis 
globais é reservado apenas em um lugar, no arquivo-objeto table.o. 

Se você é iniciante em programação na linguagem C e não entende bem o que está ocor- 
rendo aqui, não se apavore; os detalhes não são realmente importantes. Essa é uma maneira 
polida de reformular o famoso comentário de Ken Thompson, citado anteriormente. A in- 
clusão múltipla de arquivos de cabeçalho pode causar problemas para alguns ligadores, pois 
pode levar a múltiplas declarações de variáveis incluídas. O uso de EXTERN é simplesmente 
uma maneira de tornar o MINIX 3 mais portável para que possa ser vinculado em máquinas 
cujos ligadores não aceitam variáveis com definição múltipla. 

PRIVATE é definida como um sinônimo de static. As funções e os dados que não são 
referenciados fora dos arquivos nos quais aparecem, são sempre declarados como PRIVATE 
para evitar que seus nomes sejam visíveis fora desses arquivos. Como regra geral, todas as 
variáveis e funções devem ser declaradas com escopo local, se possível. PUBLIC é definida 
como uma string nula. Um exemplo de núcleo /proc.c pode ajudar a esclarecer isso. A de- 
claração 


PUBLIC void lock dequeue(rp) 
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sai do pré-processador C como 
void lock dequeue(rp) 


que, de acordo com as regras de escopo da linguagem C, significa que o nome de função 
lock dequeue(rp) é exportado do arquivo e a função pode ser chamada a partir de qualquer 
parte, em qualquer arquivo vinculado no mesmo binário, neste caso, em qualquer parte do 
núcleo. Outra função declarada no mesmo arquivo é 


PRIVATE void dequeue(rp) 
que, pré-processada, se torna 
static void dequeue(rp) 


Essa função só pode ser chamada a partir do código que esteja no mesmo arquivo-fonte. 
PRIVATE e PUBLIC não são necessárias, mas são tentativas de desfazer o dano causado pelas 
regras de escopo da linguagem C (o padrão é exportar os nomes para fora do arquivo; deveria 
ser exatamente o contrário). 

O resto de const.h define constantes numéricas utilizadas por todo o sistema. Uma se- 
ção de const.h é dedicada às definições de máquina ou dependentes da configuração. Por 
exemplo, por todo o código-fonte, a unidade básica de alocação de memória é o click. Dife- 
rentes valores para o tamanho do click podem ser escolhidos para diferentes arquiteturas de 
processador. Para plataformas Intel, ele é de 1024 bytes. Alternativas para arquiteturas Intel, 
Motorola 68000 e Sun SPARC são definidas nas linhas 2673 a 2681. Esse arquivo também 
contém as macros MAX e MIN; portanto, podemos escrever 


z = MAX (x,y); 


para atribuir o maior de x e y a z. 

Type.h (linha 2800) é outro arquivo incluído em toda compilação, por meio dos ca- 
beçalhos mestres. Ele contém várias definições de tipo importantes, junto com os valores 
numéricos relacionados. 

As duas primeiras estruturas definem dois tipos diferentes de mapa de memória, um 
para regiões de memória local (dentro do espaço de dados de um processo) e outro para áreas 
de memória remota, como um disco em RAM (linhas 2828 a 2840). Este é um bom lugar para 
citar os conceitos usados ao se referir à memória. Conforme acabamos de mencionar, o click é 
a unidade básica de medida de memória; no MINIX 3, para processadores Intel, um click vale 
1024 bytes. A memória é medida como phys clicks, que pode ser usado pelo núcleo para 
acessar qualquer elemento da memória, em qualquer parte do sistema, ou como vir clicks, 
usado por processos que não são o núcleo. Uma referência de memória vir. clicks é sempre 
com relação à base de um segmento de memória atribuído a um processo em particular e o 
núcleo fregiientemente precisa fazer transferências entre endereços virtuais (isto é, baseados 
no processo) e físicos (baseados na memória RAM). A inconveniência disso é compensada 
pelo fato de que um processo pode fazer todas as suas próprias referências de memória em 
vir. clicks. 

Alguém poderia supor que a mesma unidade poderia ser usada para especificar o ta- 
manho de um dos tipos de memória, mas é vantajoso utilizar vir clicks para especificar o 
tamanho de uma unidade de memória alocada para um processo, pois quando essa unidade é 
usada, é feita uma verificação para garantir que não seja acessada nenhuma memória fora do 
que foi especificamente atribuído ao processo corrente. Essa é uma característica importante 
do modo protegido dos processadores Intel modernos, como a família Pentium. Sua ausên- 


146 


SISTEMAS OPERACIONAIS 


cia nos primeiros processadores 8086 e 8088 causou algumas dores de cabeça no projeto das 
primeiras versões do MINIX. 

Outra estrutura importante definida aqui é sigmsg (linhas 2866 a 2872). Quando um 
sinal é capturado, o núcleo precisa dar um jeito para que, na próxima vez que o processo 
sinalizado executar, ele execute a rotina de tratamento de sinal, em vez de continuar a exe- 
cução onde foi interrompida. O gerenciador de processos realiza a maior parte do trabalho 
de gerenciamento de sinais; quando um sinal é capturado, ele passa uma estrutura como essa 
para o núcleo. 

A estrutura kinfo (linhas 2875 a 2893) é usada para transmitir informações sobre o 
núcleo para outras partes do sistema. O gerenciador de processos usa essas informações ao 
configurar sua parte da tabela de processos. 

As estruturas de dados e os protótipos de função para comunicação entre processos 
são definidos em ipc.h (linha 3000). A definição mais importante nesse arquivo é message, 
nas linhas 3020 a 3032. Embora pudéssemos ter definido message como um array de um cer- 
to número de bytes, é considerada uma prática de programação melhor fazer com que ela seja 
uma estrutura contendo uma união dos vários tipos de mensagem possíveis. São definidos 
sete formatos de mensagem, mess 1 amess 8 (o tipo mess 6 é obsoleto). Uma mensagem 
é uma estrutura contendo um campo m source, informando quem enviou a mensagem, um 
campo m. type, informando qual é o tipo da mensagem (por exemplo, SYS EXEC para a tare- 
fa de sistema) e os campos de dados. 

Os sete tipos de mensagem aparecem na Figura 2-34. Na figura, quatro tipos de men- 
sagem, os dois primeiros e os dois últimos, parecem idênticos. Eles são idênticos apenas em 
termos do tamanho dos elementos de dados, mas muitos dos tipos de dados são diferentes. 
Acontece que, em uma CPU Intel com um tamanho de palavra de 32 bits, os tipos de dados 
int, long e de ponteiro são todos de 32 bits, mas esse não é necessariamente o caso em outro 
tipo de hardware. A definição de sete formatos distintos torna mais fácil recompilar o MINIX 
3 para uma arquitetura diferente. 

Quando é necessário enviar uma mensagem contendo, por exemplo, três inteiros e três 
ponteiros (ou três inteiros e dois ponteiros), deve ser usado o primeiro formato da Figura 2- 
34. O mesmo se aplica para os outros formatos. Como se atribui um valor ao primeiro inteiro 
no primeiro formato? Suponha que a mensagem se chame x. Então, x.m u se refere à parte da 
união da estrutura da mensagem. Para nos referirmos à primeira das seis alternativas na união, 
usamos x.m u.m ml. Finalmente, para obtermos o primeiro inteiro nessa estrutura, escreve- 
mos x.m u.m ml.mlil. Isso é bastante longo; portanto, nomes de campo bem mais curtos 
são definidos como macros, após a definição da mensagem em si. Assim, x.m1 il pode ser 
usado, em vez de x.m um ml.mlil. Todos os nomes curtos têm a forma da letra m, o número 
do formato, um sublinhado, uma ou duas letras indicando se o campo é um inteiro, ponteiro, 
longo, caractere, array de caracteres ou função, e um número em segiiência para distinguir 
múltiplas instâncias do mesmo tipo dentro de uma mensagem. 

Enquanto discutimos os formatos das mensagens, este é um bom lugar para notar que 
um sistema operacional e seu compilador freqientemente possuem um entendimento a res- 
peito de uma série de coisas como o layout das estruturas de dados, e isso pode facilitar a vida 
do projetista. No MINIX 3, os campos int nas mensagens às vezes são usados para conter 
tipos de dados unsigned. Em alguns casos, isso poderia causar estouro de representação nu- 
mérica (overflow), mas o código foi escrito usando o conhecimento de que o compilador do 
MINIX 3 copia os tipos unsigned em valores int e vice-versa, sem alterar os dados nem gerar 
código para detectar estouro. Uma estratégia mais compulsiva seria substituir cada campo int 
por um union de um valor int e um unsigned. O mesmo se aplica aos campos long nas mensa- 
gens; alguns deles podem ser usados para passar dados unsigned long. Estamos trapaceando 
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aqui? Talvez um pouco, alguém poderia dizer, mas se você quiser portar o MINIX 3 para uma 
nova plataforma, muito claramente o formato exato das mensagens é algo em que se deve 
prestar muita atenção e agora já alertamos que o comportamento do compilador é outro fator 
que precisa de cuidado. 


mivii m2 il m3_il m4 11 m7_il m8_i1 


m3_ca1 


Figura 2-34 Os sete tipos de mensagem usados no MINIX 3. Os tamanhos dos elementos da mensa- 
gem variam dependendo da arquitetura da máquina; este diagrama ilustra os tamanhos para CPUs que 
possuem ponteiros em 32 bits, como aqueles dos membros da família Pentium. 


Também definidos em ipc.h estão os protótipos das primitivas de passagem de men- 
sagem descritas anteriormente (linhas 3095 a 3101). Além das importantes primitivas send, 
receive, sendrec e notify, várias outras são definidas. Nenhuma delas é muito usada; na verda- 
de, poderia se dizer que elas são sobreviventes dos primeiros estágios do desenvolvimento do 
MINIX 3. Os programas de computador antigos fazem boas escavações arqueológicas. Elas 
podem desaparecer em um lançamento futuro. Contudo, se não as explicarmos agora, sem 
dúvida alguns leitores se preocuparão com elas. As chamadas não-bloqueantes de nb send e 
nb receive foram substituídas principalmente por notify, que foi implementada posteriormen- 
te e considerada como uma solução melhor para o problema do envio ou da verificação de 
uma mensagem sem bloqueio. O protótipo de echo não tem campo de origem nem de destino. 
Essa primitiva não tem utilidade em código de produção, mas foi útil durante o desenvolvi- 
mento para testar o tempo que demorava para enviar e receber uma mensagem. 
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Um outro arquivo em include/minix/, syslib.h (linha 3200), é quase universalmente usa- 
do por meio da inclusão nos cabeçalhos mestres de todos os componentes em espaço de usuá- 
rio do MINIX 3. Esse arquivo não foi incluído no arquivo de cabeçalho mestre do núcleo, 
src/kernel/kernel.h, porque o núcleo não precisa de funções de biblioteca para acessar a si 
mesmo. Syslib.h contém protótipos de funções de biblioteca C chamados dentro do sistema 
operacional para acessar outros serviços do próprio sistema. 

Não descreveremos os detalhes das bibliotecas C neste texto, mas muitas funções de 
biblioteca são padronizadas e estarão disponíveis para qualquer compilador C. Entretanto, 
as funções C referenciadas por syslib.h são, é claro, muito específicas para o MINIX 3 e uma 
mudança para uma nova plataforma de hardware, com um compilador diferente, exige por- 
tar essas funções de biblioteca. Felizmente, isso não é difícil, pois a maioria dessas funções 
simplesmente extrai os parâmetros da chamada de função e os insere em uma estrutura de 
mensagem; em seguida, envia a mensagem e extrai os resultados da mensagem de resposta. 
Muitas dessas funções de biblioteca são definidas em pouco menos de uma dezena de linhas 
de código C. 

Vale notar nesse arquivo as quatro macros para acessar portas de E/S usando dados do 
tipo byte ou palavra, e o protótipo da função sys. sdevio, à qual as quatro macros se referem 
(linhas 3241 a 3250). Fornecer uma maneira para os drivers de dispositivo solicitarem a leitu- 
ra e a escrita em portas de E/S pelo núcleo é uma parte fundamental do projeto do MINIX 3, 
pois permite mover todos esses drivers para espaço de usuário. 

Algumas funções que poderiam ter sido definidas em syslib.h estão em um arquivo 
separado, sysutil.h (linha 3400), pois o código objeto delas é compilado em uma biblioteca 
separada. Aqui, duas funções precisam um pouco mais de explicação. A primeira é printf (li- 
nha 3442). Se você tiver experiência com programação em C, vai reconhecer que printf é uma 
função de biblioteca padrão, referenciada em quase todos os programas. 

Entretanto, essa não é a função printf que você pensa. A versão de printf da biblioteca 
padrão não pode ser usada dentro de componentes do sistema. Dentre outras coisas, a função 
printf padrão se destina a escrever na saída padrão e deve ser capaz de formatar números em 
ponto flutuante. Usar a saída padrão exige percorrer o sistema de arquivos, mas é desejável 
que, em caso de erros, um componente do sistema seja capaz de exibir uma mensagem de 
erro sem a intervenção de outros componentes do sistema. Além disso, o suporte para toda 
a gama de especificações de formato que podem ser utilizadas com a função printf padrão 
aumenta o código sem nenhum objetivo prático. Portanto, é compilada na biblioteca de utili- 
tários do sistema uma versão simplificada de printf, que faz apenas o que é necessário para os 
componentes do sistema operacional. Isso é encontrado pelo compilador em um local depen- 
dente da plataforma; para sistemas Intel de 32 bits, o local é /usr/lib/i586/libsysutil.a. Quando 
o sistema de arquivos, o gerenciador de processos ou outra parte do sistema operacional é 
ligado às funções de biblioteca, essa versão é encontrada antes que a biblioteca padrão seja 
pesquisada. 

Na próxima linha aparece um protótipo para kputc. Ela é chamada pela versão de siste- 
ma de printf para realizar o trabalho de exibir caracteres no console. Entretanto, mais truques 
estão envolvidos aqui. Kputc é definida em vários lugares. Existe uma cópia na biblioteca de 
utilitários do sistema, a qual será usada, por padrão. Mas várias partes do sistema definem 
suas próprias versões. Veremos uma quando estudarmos a interface do console, no próximo 
capítulo. O driver de log (que não será descrito em detalhes aqui) também define sua própria 
versão. Existe até uma definição de kputc no próprio núcleo, mas esse é um caso especial. O 
núcleo não utiliza printf. Uma função de impressão especial, kprintf, é definida como parte do 
núcleo e é usada quando o núcleo precisa imprimir. 


CAPÍTULO 2 e PROCESSOS 149 


Quando um processo precisa executar uma chamada de sistema do MINIX 3, ele envia 
uma mensagem para o gerenciador de processos (ou PM, de process manager) ou para o 
sistema de arquivos (ou FS, de file system). Cada mensagem contém o número da chamada 
de sistema desejada. Esses números são definidos no próximo arquivo, callnr.h (linha 3500). 
Alguns números não são usados; eles estão reservados para chamadas ainda não implemen- 
tadas ou representam chamadas implementadas em outras versões, que agora são manipula- 
das pelas funções de biblioteca. Perto do final do arquivo, são definidos alguns números de 
chamada que não correspondem às chamadas mostradas na Figura 1-9. Svrctl (mencionada 
anteriormente), ksig, unpause, revive e task reply são usadas apenas dentro do próprio sis- 
tema operacional. O mecanismo de chamada de sistema é uma maneira conveniente de im- 
plementá-las. Na verdade, como não serão usadas por programas externos, essas chamadas 
de sistema podem ser modificadas nas novas versões do MINIX 3, sem medo de danificar 
programas de usuário. 

O próximo arquivo é com.h (linha 3600). Uma interpretação do nome do arquivo diz 
que ele significa comum, outra diz que significa comunicação. Esse arquivo fornece defini- 
ções comuns usadas para a comunicação entre servidores e drivers de dispositivo. Nas linhas 
3623 a 3626 são associados números as tarefas. Para distingui-los dos números de processo, 
os números de tarefa são negativos. Nas linhas 3633 a 3640 são definidos números de proces- 
sos carregados na imagem de boot. Note que esses números são entradas (indíces) na tabela 
de processos; eles não devem ser confundidos com os números de idendificação de processo 
(PID — Process IDentifier). 

A seção seguinte de com.h define como as mensagens são construídas para executar 
uma operação notify. Os números de processo são usados na geração do valor passado no 
campo m type da mensagem. Os tipos de mensagem para notificações e outras mensagens 
definidas nesse arquivo são construídos pela combinação de um valor de base que significa 
uma categoria de tipo, com um número indicando o tipo específico. O restante desse arquivo 
é um compêndio de macros que transformam identificadores em números codificados para 
tipos de mensagem e nomes de campo. 

Alguns outros arquivos em include/minix/ estão listados no Apêndice B. Devio.h (linha 
4100) define tipos e constantes que suportam acesso do espaço de usuário às portas de E/S, 
assim como algumas macros que tornam mais fácil escrever código especificando portas e 
valores. Dmap.h (linha 4200) define uma struct e um array dessa struct, ambos chamados 
dmap. Essa tabela é usada para relacionar números de dispositivo principais com as funções 
que os suportam. Também são definidos números de dispositivo principais e secundários para 
o driver de dispositivo de memória e números de dispositivo principais para outros drivers de 
dispositivo importantes. 

Include/minix/ contém vários arquivos de cabeçalho especializados adicionais, não lis- 
tados no Apêndice B, mas que devem estar presentes para compilar o sistema. Um deles é 
u64.h, que fornece suporte para operações aritméticas de inteiros de 64 bits, necessárias para 
manipular endereços de disco em unidades de disco de alta capacidade. Nem mesmo se so- 
nhava com elas, quando o UNIX, a linguagem C, os processadores da classe Pentium e o MI- 
NIX foram concebidos. Uma versão futura do MINIX 3 poderá ser escrita em uma linguagem 
que tenha suporte interno para inteiros de 64 bits em processadores com registradores de 64 
bits; até lá, as definições presentes em u64.h fornecem uma solução alternativa. 

Resta mencionar três arquivos. Keymap.h define as estruturas de dados utilizadas para 
customizar layouts de teclado para os conjuntos de caracteres necessários aos diferentes idio- 
mas. Ele também é necessário para programas que geram e carregam essas tabelas. Bitmap. 
h fornece algumas macros para facilitar operações como ativar, reativar e testar bits. Final- 
mente, partition.h define as informações necessárias para o MINIX 3 definir uma partição de 
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disco, ou pelo seu deslocamento absoluto (em bytes) e tamanho no disco, ou por um endereço 
de cilindro, cabeçote e setor. O tipo u64 t é usado para o deslocamento e tamanho, para per- 
mitir o uso de discos grandes. Esse arquivo não descreve o layout de uma tabela de partição 
em um disco; o arquivo que faz isso está no próximo diretório. 

O último diretório de cabeçalho especializado que consideraremos, include/ibm/, con- 
tém arquivos que fornecem definições relacionadas à família IBM PC de computadores. 
Como a linguagem C conhece apenas endereços de memória e não tem meios de acessar 
endereços de porta de E/S, a biblioteca contém rotinas escritas em linguagem assembly para 
ler e escrever a partir dessas portas. As várias rotinas disponíveis são declaradas em ibm/por- 
tio.h (linha 4300). Estão disponíveis todas as rotinas de entrada e saída possíveis para tipos 
de dados byte, integer e long, isoladamente ou como strings, de inb (um byte de entrada) até 
outsl (saída de uma string de valores long). Rotinas de baixo nível no núcleo também talvez 
precisem desativar ou reativar interrupções de CPU, que também são ações que a linguagem 
C não consegue manipular. A biblioteca fornece código assembly para fazer isso e intr disa- 
ble e intr enable estão declarados nas linhas 4325 e 4326. 

O próximo arquivo nesse diretório é interrupt.h (linha 4400), que define endereço de 
portas e posições de memória usadas pelo controlador de interrupção e pela BIOS em siste- 
mas compatíveis com PC. Finalmente, mais portas de E/S estão definidas em ports.h (linha 
4500). Esse arquivo fornece os endereços necessários para acessar a interface de teclado e o 
temporizador usado pelo relógio. 

Vários arquivos adicionais em include/ibm/, com dados específicos da IBM, não são lis- 
tados no Apêndice B, mas eles são fundamentais e devem ser mencionados. Bios.h, memory.h 
e partition.h estão abundantemente comentados e são dignos de serem lidos, caso você queira 
saber mais sobre o uso de memória ou sobre as tabelas de partição de disco. Cmos.h, cpu.h 
e int86.h fornecem informações adicionais sobre portas, bits de flag da CPU e a chamada de 
serviços da BIOS e do DOS no modo de 16 bits. Finalmente, diskparm.h define uma estrutura 
de dados necessária para formatar um disquete. 


Estruturas de dados de processo e arquivos de cabeçalho 


Vamos nos aprofundar agora e ver como é o código em src/kernel. Nas duas seções ante- 
riores, estruturamos nossa discussão em torno de um trecho de um cabeçalho mestre típico; 
primeiramente, vimos o cabeçalho mestre real do núcleo, kernel.h (linha 4600). Ele começa 
definindo três macros. A primeira, POSIX SOURCE, é uma macro de teste de recurso 
definida pelo próprio padrão POSIX. Todas essas macros são obrigadas a começar com o 
caractere de sublinhado, “_”. O efeito de definir a macro POSIX SOURCE é garantir que 
todos os símbolos exigidos pelo padrão, e os que são explicitamente permitidos, mas não 
obrigatórios, sejam visíveis, enquanto se oculta os símbolos adicionais que são extensões ex- 
tra-oficiais do POSIX. Já mencionamos as duas próximas definições: a macro MINIX anula 
o efeito de POSIX SOURCE para extensões definidas pelo MINIX 3 e SYSTEM pode ser 
testada ao compilar código de sistema (e não código de usuário), onde for importante fazer 
algo de maneira diferente. Kernel.h inclui então outros arquivos de cabeçalho de include/ e 
seus subdiretórios include/sys/, include/minix/ e include/ibm/, considerando todos aqueles 
referidos na Figura 2-32. Já discutimos todos esses arquivos nas duas seções anteriores. Fi- 
nalmente, são incluídos seis arquivos de cabeçalho adicionais do diretório local, src/kernel; 
seus nomes aparecem entre aspas. 

Kernel.h torna possível garantir que todos os arquivos-fonte compartilhem um grande 
número de definições importantes, escrevendo-se a linha 


tinclude “kernel.h” 
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em cada um dos outros arquivos-fonte do núcleo. Como a ordem de inclusão de arquivos 
de cabeçalho às vezes é importante, kernel.h também garante que essa ordenação seja feita 
corretamente e de uma vez por todas. Isso leva a um nível mais alto a técnica de “fazer direito 
uma vez e depois esquecer os detalhes”, incorporada no conceito de arquivo de cabeçalho. 
Cabeçalhos mestres semelhantes são fornecidos nos diretórios dos fontes de outros compo- 
nentes do sistema, como o sistema de arquivos e o gerenciador de processos. 

Passemos agora a examinar os arquivos de cabeçalho locais incluídos em kernel.h. Pri- 
meiramente, temos um outro arquivo chamado config.h, o qual, semelhantemente ao arquivo 
em nível de sistema include/minix/config.h, deve ser incluído antes de qualquer um dos outros 
arquivos de inclusão locais. Assim como temos arquivos const.h e type.h no diretório de cabe- 
çalho comum include/minix/, também temos arquivos const.h. e type.h no diretório fonte do 
núcleo, src/kernel/. Os arquivos em include/minix/ são colocados lá porque são necessários 
para muitas partes do sistema, incluindo programas executados sob o controle do sistema. 
Os arquivos em src/kernel/ fornecem as definições necessárias apenas para a compilação do 
núcleo. O sistema de arquivos e gerenciador de processos e outros diretórios fonte do sistema 
também contêm arquivos const.h e type.h para definir constantes e tipos necessários apenas 
para essas partes do sistema. Dois dos outros arquivos incluídos no cabeçalho mestre, proto.h 
e glo.h, não têm correlatos nos diretórios include/ principais, mas veremos que eles também 
têm correlatos utilizados na compilação do sistema de arquivos e do gerenciador de proces- 
sos. O último arquivo de cabeçalho local incluído em kernel.h é outro ipc.h. 

Como esta é a primeira vez que ele aparece em nossa discussão, observe que, no início 
de kernel/config.h existe uma sequência Hifndef ... tdefine para evitar problemas, caso o ar- 
quivo seja incluído várias vezes. Já vimos a idéia geral antes. Mas, note que a macro definida 
aqui é CONFIG. H, sem o sublinhado. Assim, ela é diferente da macro CONFIG H definida 
em include/minix/config.h. 

A versão do núcleo de config.h reúne em um só lugar várias definições que provavelmen- 
te não precisarão de alterações, caso seu interesse no MINIX 3 seja estudar o funcionamento 
de um sistema operacional ou usar este sistema operacional em um computador de propósi- 
to geral convencional. Entretanto, suponha que você queira fazer uma versão do MINIX 3 
realmente pequena, para controlar um instrumento científico ou um telefone celular feito em 
casa. As definições nas linhas 4717 a 4743 permitem a desativação seletiva de chamadas de 
núcleo. Eliminar funcionalidade desnecessária também reduz os requisitos de memória, pois 
o código necessário para tratar de cada chamada de núcleo é compilado condicionalmente, 
usando as definições das linhas 47177 a 4743. Se alguma função for desativada, o código ne- 
cessário para executá-la será omitido do binário de sistema. Por exemplo, um telefone celular 
talvez não precisasse criar novos processos (fork); portanto, o código para fazer isso poderia 
ser omitido do arquivo executável, resultando em um consumo de memória menor. A maioria 
das outras constantes definidas nesse arquivo controla parâmetros básicos. Por exemplo, no 
tratamento de interrupções, é usada uma pilha especial de tamanho K STACK BYTES. Esse 
valor é configurado na linha 4772. O espaço para essa pilha é reservado dentro de mpx386.s, 
um arquivo em linguagem assembly. 

Em const.h (linha 4800), uma macro para converter endereços virtuais relativos à base 
do espaço de memória do núcleo em endereços físicos é definida na linha 4814. Uma função 
C, umap local, é definida em outra parte do código do núcleo, para que o núcleo possa fazer 
essa conversão para outros componentes do sistema, mas, para uso dentro do núcleo, a macro 
é mais eficiente. Diversas outras macros úteis são definidas aqui, incluindo várias para mani- 
pular mapas de bits. Um mecanismo de segurança importante incorporado no hardware Intel 
é ativado aqui, por duas linhas de definição de macro. O Processor Status Word (PSW) é um 
registrador da CPU e os bits 1/O Protection Level (IOPL) dentro dele definem se o acesso 
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ao sistema de interrupção e às portas de E/S é permitido ou negado. Nas linhas 4850 e 4851, 
são definidos diferentes valores de PSW que determinam esse acesso para processos normais 
e privilegiados. Esses valores são colocados na pilha como parte da execução de um novo 
processo. 

No próximo arquivo que consideraremos, type.h (linha 4900), a struct memory (linhas 
4925 a 4928) utiliza dois valores, endereço de base e tamanho, para especificar exclusivamen- 
te uma área da memória. 

Type.h define vários outros protótipos e estruturas de dados utilizados em qualquer im- 
plementação do MINIX 3. Por exemplo, são definidas duas estruturas de dados, kmessages, 
usada para mensagens de diagnóstico do núcleo, e randomness, usada pelo gerador de núme- 
ros aleatórios. Type.h também contém várias definições de tipo dependentes da máquina. Para 
tornar o código mais curto e legível, removemos o código condicional e as definições para 
outros tipos de CPU. Mas você deve reconhecer que definições como a struct stackframe _s 
(linhas 4955 a 4974), que estabelecem como os registradores da máquina são salvos na pi- 
lha, são específicas dos processadores Intel de 32 bits. Para outra plataforma, stackframe _s 
seria definida em termos da estrutura de registrador da CPU a ser usada. Outro exemplo é a 
struct segdesc s (linhas 4976 a 4983), que faz parte do mecanismo de proteção que impede 
os processos de acessarem regiões de memória fora daquelas designadas para eles. Para uma 
outra CPU, segdesc s poderia nem mesmo existir, dependendo do mecanismo usado para 
implementar proteção de memória. 

Outro ponto a destacar a respeito de estruturas como essas é que é necessário garantir 
que todos os dados necessários estejam presentes, mas possivelmente isso não é suficiente 
para se obter um desempenho excelente. A estrutura de dados stackframe _s deve ser ma- 
nipulada por código em linguagem assembly. Defini-la de uma forma que possa ser lida ou 
gravada eficientemente por código em linguagem assembly reduz o tempo exigido para uma 
troca de contexto. 

O próximo arquivo, proto.h (linha 5100), fornece os protótipos de todas as funções que 
devem ser conhecidas fora do arquivo em que são definidas. Todas são escritas usando-se 
a macro PROTOTYPE discutida na seção anterior e, portanto, o núcleo do MINIX 3 pode 
ser compilado com um compilador C clássico (Kernighan e Ritchie), com o compilador C 
original do MINIX 3, ou com um compilador C Standard ANSI moderno, como o que faz 
parte da distribuição do MINIX 3. Vários desses protótipos são dependentes do sistema, 
incluindo as rotinas de tratamento de interrupção e exceção e as funções escritas em lingua- 
gem assembly. 

Em glo.h (linha 5300), encontramos as variáveis globais do núcleo. O objetivo da macro 
EXTERN foi descrito na discussão sobre include/minix/const.h. Normalmente, ela se expande 
em extern. Note que muitas definições presentes em glo.h são precedidas por essa macro. 
O símbolo EXTERN é forçado a ser indefinido quando esse arquivo é incluído em table.c, 
onde a macro TABLE é definida. Assim, o espaço de armazenamento real para as variáveis 
definidas dessa maneira é reservado quando glo.h é incluído na compilação de table.c. Incluir 
glo.h em outros arquivos-fonte torna as variáveis presentes em table.c conhecidas de outros 
módulos presentes no núcleo. 

Algumas das estruturas de dados de informação do núcleo utilizadas na inicialização 
são descritas aqui. Aout (linha 5321) contém o endereço de um array dos cabeçalhos de to- 
dos os componentes da imagem do sistema MINIX 3. Note que esses são endereços físicos; 
ou seja, endereços relativos ao espaço de endereçamento inteiro do processador. Conforme 
veremos posteriormente, o endereço físico de aout será passado do monitor de inicialização 
para o núcleo, quando o MINIX 3 for inicializado; portanto, as rotinas de inicialização do 
núcleo podem obter os endereços de todos os componentes do MINIX 3 a partir do espaço de 
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memória do monitor. Kinfo (linha 5322) também é uma informação importante. Lembre-se 
de que a struct foi definida em include/minix/type.h. Assim como o monitor de inicialização 
utiliza aout para passar informações sobre todos os processos presentes na imagem de boot 
para o núcleo, o núcleo preenche os campos de kinfo com informações sobre si mesmo, que 
outros componentes do sistema talvez precisem conhecer. 

A próxima seção de glo.h contém variáveis relacionadas ao controle de processo e à 
execução do núcleo. Prev ptr, proc ptr e next ptr apontam para as entradas da tabela de pro- 
cessos do processo anterior, corrente e do próximo a ser executado. Bill ptr também aponta 
para uma entrada da tabela de processos; ela mostra para qual processo os tiques de relógio 
usados estão sendo contabilizados. Quando um processo de usuário chama o sistema de ar- 
quivos e este está em execução, proc ptr aponta para o processo de sistema de arquivos. 
Entretanto, bill ptr apontará para o processo usuário que está fazendo a chamada, pois o 
tempo de CPU utilizado pelo sistema de arquivos é considerado como tempo de sistema para 
quem fez a chamada. Nunca ouvimos falar de um sistema MINIX cujo proprietário cobrasse 
pelo uso do tempo da CPU, mas isso poderia ser feito. A próxima variável, k reenter, é usada 
para contar execuções aninhadas do código do núcleo, como acontece quando ocorre uma 
interrupção no momento em que o próprio núcleo (e não um processo de usuário) está em 
execução. Isso é importante, pois trocar de contexto de um processo de usuário para o núcleo 
ou vice-versa é diferente (e mais dispendioso) de entrar no núcleo novamente. Quando um 
serviço de interrupção termina, é importante que ele determine se o controle deve permanecer 
com o núcleo ou se um processo em espaço de usuário deve ser reiniciado. Essa variável tam- 
bém é testada por algumas funções que habilitam e desabilitam interrupções, como lock en- 
queue. Se tal função é executada com as interrupções desabilitadas, as mesmas não devem 
ser reabilitadas em momentos inapropriados. Finalmente, nesta seção existe um contador de 
tiques de relógio perdidos. Discutiremos o modo como um tique de relógio pode ser perdido 
e o que é feito com relação a isso, quando tratarmos da tarefa de relógio. 

As últimas variáveis definidas em glo.h são declaradas aqui porque devem ser conhecidas 
por todo o código do núcleo, mas elas são declaradas como extern, em vez de EXTERN, pois 
são variáveis inicializadas, um recurso da linguagem C. O uso da macro EXTERN não é com- 
patível com a inicialização no estilo C, pois uma variável só pode ser inicializada uma vez. 

Das tarefas executadas em espaço de núcleo, atualmente apenas a tarefa de relógio e a 
tarefa de sistema, têm suas próprias pilhas dentro de t stack. Durante o tratamento de inter- 
rupção, o núcleo utiliza uma pilha separada, mas ela não é declarada aqui, pois só é acessada 
pela rotina no nível da linguagem assembly que trata do processamento de interrupções e não 
precisa ser conhecida globalmente. O último arquivo incluído em kernel.h e, portanto, usado 
em toda compilação, é ipc.h (linha 5400). Ele define várias constantes usadas na comunica- 
ção entre processos. Vamos discuti-las posteriormente, quando estudarmos o arquivo onde 
elas são utilizadas, kernel/proc.c. 

Muitos outros arquivos de cabeçalho do núcleo são amplamente usados, embora não 
o suficiente para serem incluídos em kernel.h. O primeiro deles é proc.h (linha 5500), que 
define a tabela de processos do núcleo. O estado completo de um processo é definido pelos 
dados do processo na memória, além das informações presentes em sua entrada na tabela de 
processos. O conteúdo dos registradores da CPU é armazenado aqui, quando um processo 
não está em execução, e depois restaurado, quando a execução é retomada. É isso que torna 
possível dar a ilusão de que vários processos estão em execução simultaneamente e interagin- 
do, embora, em dado momento, uma única CPU pode estar executando instruções de apenas 
um processo. O tempo gasto pelo núcleo para salvar e restaurar o estado do processo durante 
cada troca de contexto é necessário, mas obviamente é um tempo durante o qual o trabalho 
dos processos em si é suspenso. Por isso, essas estruturas são projetadas para serem eficien- 


154 


SISTEMAS OPERACIONAIS 


tes. Conforme observado no comentário presente no início de proc.h, muitas rotinas escritas 
em linguagem assembly também acessam essas estruturas, e outro cabeçalho, sconst.h, define 
deslocamentos para campos na tabela de processos para uso por código em assembly. Assim, 
a alteração de uma definição em proc.h pode necessitar de uma alteração em sconst.h. 

Antes de prosseguirmos, devemos mencionar que, devido à organização de micronúcleo 
do MINIX 3, a tabela de processos que vamos discutir aqui se equipara às tabelas presentes 
no gerenciador de processos e nos sistemas de arquivos, as quais contêm entradas por proces- 
so relevantes à função dessas partes do MINIX 3. Juntas, essas três tabelas são equivalentes 
à tabela de processos de um sistema operacional com uma organização monolítica, mas, por 
enquanto, quando falarmos da tabela de processos, estaremos falando apenas sobre a tabela 
de processos do núcleo. As outras serão discutidas em capítulos posteriores. 

Cada entrada na tabela de processos é definida como uma estrutura de dados proc (linhas 
5516 a 5545). Cada entrada contém campos para o armazenamento dos registradores da CPU, 
ponteiro de pilha, estado, mapa de memória, limite da pilha, id de processo, informações de 
contabilização, temporizadores de alarme e informação de mensagem do processo. A primeira 
parte de cada entrada da tabela de processos é uma estrutura de dados stackframe _s. Um pro- 
cesso que já está na memória é posto em execução carregando-se seu ponteiro de pilha com 
o endereço de sua entrada na tabela de processos e recuperando-se todos os registradores da 
CPU dessa estrutura. 

Contudo, há mais informações no estado de um processo do que apenas os registradores 
da CPU e os dados presentes na memória. No MINIX 3, cada processo tem um ponteiro para 
uma estrutura priv em sua entrada na tabela de processos (linha 5522). Essa estrutura define 
as origens e destinos de mensagens permitidos para o processo e muitos outros privilégios. 
Veremos os detalhes posteriormente. Por enquanto, note que cada processo de sistema tem 
um ponteiro para uma cópia exclusiva dessa estrutura, mas os privilégios de usuário são to- 
dos iguais — os ponteiros de todos os processos de usuário apontam para a mesma cópia da 
estrutura. Também existe um campo de um byte para um conjunto de flags de bit, p rts flags 
(linha 5523). O significado dos bits será descrito a seguir. Configurar qualquer bit como 1 
significa que um processo não é executável; portanto, um valor zero nesse campo indica que 
um processo está pronto. 

Cada entrada na tabela de processos fornece espaço para informações que podem ser 
necessárias para o núcleo. Por exemplo, o campo p max priority (linha 5526) indica em qual 
fila de escalonamento o processo deve ser colocado quando estiver pronto para executar pela 
primeira vez. Como a prioridade de um processo pode ser reduzida, caso ele impeça a execu- 
ção de outros processos, também existe um campo p priority que é inicialmente configurado 
igual à p max priority. P priority é o campo que realmente determina a fila usada sempre 
que o processo está pronto. 

O tempo usado por cada processo é registrado nas duas variáveis clock t, nas linhas 
5532 e 5533. Essa informação deve ser acessada pelo núcleo e seria ineficiente armazenar 
isso no próprio espaço de memória de um processo, embora logicamente isso pudesse ser 
feito. P nextready (linha 5535) é usado para encadear processos nas filas do escalonador. 

Os campos seguintes contêm informações relacionadas às mensagens entre processos. 
Quando um processo não consegue concluir uma operação send porque o destino não está 
esperando, o remetente é colocado em uma fila apontada pelo ponteiro p caller q (linha 
5536) do destino. Desse modo, quando o destino finalmente executa uma operação receive, 
é fácil encontrar todos os processos que estão querendo enviar mensagens para ele. O campo 
pq link (linha 5537) é usado para encadear os membros da fila. 

O método rendez-vous de passagem de mensagens se torna possível graças ao espaço de 
armazenamento reservado nas linhas 5538 a 5540. Quando um processo executa uma opera- 
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ção receive e não há nenhuma mensagem esperando por isso, ele é bloqueado e o número do 
processo do qual ele espera a operação receive é armazenado em p geifrom. Analogamente, 
p. sendto contém o número de processo do destino quando um processo executa uma opera- 
ção send e o destinatário não está esperando. O endereço do buffer de mensagens é armaze- 
nado em p messbuf. O penúltimo campo em cada entrada da tabela de processos é p pending 
(linha 5542), um mapa de bits usado para monitorar os sinais que ainda não foram passados 
para o gerenciador de processos (porque o gerenciador de processos não está esperando uma 
mensagem). 

Finalmente, o último campo em uma entrada da tabela de processos é um array de 
caracteres, p name, para conter o nome do processo. Esse campo não é necessário para o 
gerenciamento de processos do núcleo. O MINIX 3 fornece vários dumps para depuração, 
disparados pelo pressionamento de uma tecla especial no teclado do console. Alguns deles 
permitem ver informações sobre todos os processos, com o nome de cada processo impresso 
junto com outros dados. Ter um nome significativo associado a cada processo torna mais fácil 
entender e depurar a operação do núcleo. 

Após a definição de uma entrada da tabela de processos vêm as definições de várias 
constantes usadas em seus elementos. Os diversos bits de flag que podem ser configurados em 
p.rts flags estão definidos e descritos nas linhas 5548 a 5555. Se a entrada não estiver sendo 
usada, SLOT FREE será configurado. Após uma operação fork, NO MAP é configurado para 
impedir que o processo filho seja executado, até que seu mapa de memória tenha sido confi- 
gurado. SENDING e RECEIVING indicam que o processo está bloqueado, tentando enviar 
ou receber uma mensagem. SIGNALED e SIG PENDING indicam que sinais foram recebi- 
dos e P STOP fornece suporte para rastreamento (tracing). NO PRIV é usado para impedir, 
temporariamente, que um novo processo de sistema seja executado, até que sua configuração 
esteja concluída. 

O número de filas de escalonamento e os valores permitidos para o campo p priority 
são definidos em seguida (linhas 5562 a 5567). Na versão atual desse arquivo, os processos 
de usuário podem acessar a fila de prioridade mais alta; isso provavelmente é uma sobra dos 
primeiros dias dos testes de drivers em espaço de usuário e MAX USER Q possivelmente 
deve ser ajustado para uma prioridade mais baixa (um valor numérico maior). 

A seguir, aparecem várias macros que permitem que os endereços de partes importantes 
da tabela de processos sejam definidos como constantes no momento da compilação, para 
proporcionar um acesso mais rápido em tempo de execução; em seguida, existem mais ma- 
cros para cálculos e testes em tempo de execução. A macro proc addr (linha 5577) é forneci- 
da porque não é possível ter subscritos negativos em C. Logicamente, o array proc deve ir de 
-NR TASKS a +NR PROCS. Infelizmente, em C, ele deve iniciar em 0; portanto, proc[0] se 
refere à tarefa mais negativa e assim por diante. Para tornar mais fácil monitorar qual entrada 
corresponde a qual processo, podemos escrever 


rp = proc addr(n); 


para atribuir a rp o endereço da entrada do processo n, ou positivo ou negativo. 

A tabela de processos em si é definida aqui como um array de estruturas proc, proc|NR . 
TASKS + NR PROCS] (linha 5593). Note que NR TASKS é definida em include/minix/com.h 
(linha 3630) e a constante NR PROCS é definida em include/minix/config.h (linha 2522). 
Juntas, elas definem o tamanho da tabela de processos do núcleo. NR PROCS pode ser al- 
terada para criar um sistema capaz de manipular um número maior de processos, se isso for 
necessário (por exemplo, em um servidor). 

Finalmente, várias macros são definidas para acelerar o acesso. A tabela de processos 
é acessada frequentemente e calcular um endereço em um array exige operações de multi- 
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plicação lentas; portanto, é fornecido um array de ponteiros para os elementos da tabela de 
processos, pproc addr (linha 5594). Os dois arrays, rdy head e rdy tail, são usados para 
manter as filas de escalonamento. Por exemplo, o primeiro processo na fila de usuário padrão 
é apontado por rdy head[USER Q]. 

Conforme mencionamos no início da discussão sobre proc.h, existe outro arquivo 
sconst.h (linha 5600), o qual deve ser sincronizado com proc.h, se houver alterações na es- 
trutura de tabela de processos. Sconst.h define as constantes usadas pelo código do montador, 
expressas de uma forma que pode ser utilizada por ele. Todas elas são deslocamentos na parte 
da estrutura stackframe s de uma entrada da tabela de processos. Como o código do monta- 
dor não é processado pelo compilador C, é mais simples ter tais definições em um arquivo 
separado. Além disso, como todas essas definições são dependentes da máquina, isolá-las 
aqui simplifica o processo de portar o MINIX 3 para outro processador que precise de uma 
versão diferente de sconst.h. Note que muitos deslocamentos são expressos como o valor an- 
terior mais W, que é configurado igual ao tamanho da palavra na linha 5601. Isso permite que 
o mesmo arquivo sirva para compilar uma versão de 16 ou de 32 bits do MINIX 3. 

Definições duplicadas criam um problema em potencial. Os arquivos de cabeçalho ser- 
vem para permitir o fornecimento de um único conjunto de definições correto e, então, se 
passe a utilizá-los em muitos lugares, sem a necessidade de prestar muito mais atenção nos 
detalhes. Obviamente, as definições duplicadas, como as que existem em proc.h e sconst.h, 
violam esse princípio. É claro que esse é um caso especial, mas, como tal, é exigida atenção 
especial, caso sejam feitas alterações em um desses arquivos, para garantir que os dois arqui- 
vos permaneçam consistentes. 

A estrutura de privilégios de sistema, priv, mencionada brevemente na discussão so- 
bre a tabela de processos, está completamente definida em priv.h, nas linhas 5718 a 5735. 
Primeiramente, existe um conjunto de bits de flag, s flags; em seguida, aparecem os campos 
s trap mask, s ipc from,s ipc toe s call mask, que definem quais chamadas de sistema 
podem ser iniciadas, quais mensagens de processos podem ser recebidas ou enviadas e quais 
chamadas do núcleo são permitidas. 

A estrutura priv não faz parte da tabela de processos; em vez disso, cada entrada da 
tabela de processos tem um ponteiro para uma instância dela. Apenas os processos de siste- 
ma têm cópias privadas; todos os processos de usuário apontam para a mesma cópia. Assim, 
para um processo de usuário, os campos restantes da estrutura não são relevantes, pois não 
faz sentido compartilhá-los. Esses campos são mapas de bits de notificações pendentes, in- 
terrupções e sinais de hardware, e um temporizador. Entretanto, faz sentido fornecê-los aqui 
para processos de sistema. Os processos de usuário têm notificações, sinais e temporizadores 
manipulados em seu nome pelo gerenciador de processos. 

A organização de priv.h é semelhante à de proc.h. Após a definição da estrutura priv 
vêm as definições de macros para os bits de flag, alguns endereços importantes conhecidos no 
momento da compilação e algumas macros para cálculos de endereço em tempo de execução. 
Em seguida, é definida a tabela de estruturas priv, priv/NR SYS PROCS], seguida de um 
array de ponteiros, ppriv addr[NR SYS PROCS] (linhas 5762 e 5763). O array de ponteiros 
proporciona acesso rápido, semelhante ao usado para as entradas da tabela de processos. O 
valor de STACK GUARD definido na linha 5738 é um padrão facilmente reconhecido. Sua 
utilização será vista posteriormente; o leitor fica convidado a pesquisar a Internet para conhe- 
cer a história desse valor. 

O último item em priv.h é um teste para garantir que NR SYS PROCS tenha sido defini- 
da com um valor maior do que o número de processos presentes na imagem de boot. A linha 
Herror imprimirá uma mensagem se a condição de teste for verdadeira. Embora o comporta- 
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mento possa ser diferente com outros compiladores C, com o compilador padrão do MINIX 
3 isso também cancelará a compilação. 

A tecla F4 gera um dump de depuração que mostra algumas informações da tabela de 
privilégios. A Figura 2-35 mostra algumas linhas dessa tabela para alguns processos represen- 
tativos. As entradas de flags significam: P: passível de preempção, B: passível de cobrança, 
S: sistema. Os traps significam: E: echo, S: envio, R: recepção, B: ambos, N: notificação. O 
mapa de bits tem um bit para cada um dos processos de sistema NR SYS PROCS (32) permi- 
tidos; a ordem corresponde ao campo id. (Na figura, para caber na página, apenas 16 bits são 
mostrados.) Todos os processos de usuário compartilham a id 0, que é a posição do bit mais 
à esquerda. O mapa de bits mostra que processos de usuário como init podem enviar mensa- 
gens apenas para o gerenciador de processos, para o sistema de arquivos e para o servidor de 
reencarnação, e devem usar sendrec. Os servidores e drivers mostrados na figura podem usar 
qualquer uma das primitivas de comunicação entre processos (ipc) e todos, menos memory, 
podem enviar para qualquer outro processo. 


--Nr- -id- -nome- -flags- -traps- -máscara ipc to - - - - - - 
(-4) (01) IDLE P-BS- ce. 00000000 00001111 
[-3] (02) CLOCK ---S --R-- 00000000 00001111 
[-2] (03) SYSTEM ---S- a o tao 00000000 00001111 
[-1] (04) KERNEL 8-0 non 00000000 00001111 

0 (05) pm P-- S- ESRBN 11111111 11111111 
1 (06) fs P- - S- ESRBN 11111111 11111111 
2 (07) rs P- - S- ESRBN 11111111 11111111 
3 (09) memory P- - S- ESRBN 00110111 01101111 
4 (10) log P- - S- ESRBN 11111111 11111111 
5 (08) tty P- - S- ESRBN 11111111 11111111 
6 (11) driver P- - S- ESRBN 11111111 11111111 
7 (00) init P-B-- E -- B- 00000111 00000000 


Figura 2-35 Listagem parcial de um dump de depuração da tabela de privilégios. Os privi- 
légios dos processos tarefa de relógio, servidor de arquivos, tty e init são típicos de tarefas, 
servidores, drivers de dispositivo e processos de usuário, respectivamente. O mapa de bits foi 
truncado em 16 bits. 


Outro cabeçalho incluído em vários arquivos-fonte diferentes é protect.h (linha 5800). 
Quase tudo nesse arquivo trata com detalhes da arquitetura dos processadores Intel que su- 
portam modo protegido (as séries 80286, 80386, 80486 e Pentium). Uma descrição detalhada 
desses processadores está fora dos objetivos deste livro. Basta dizer que eles contêm registra- 
dores internos que apontam para tabelas de descritores em memória. As tabelas de descri- 
tores definem como os recursos do sistema são usados e impede que os processos acessem a 
memória atribuída para outros processos. 

A arquitetura dos processadores Intel de 32 bits também fornece quatro níveis de pri- 
vilégio, dos quais o MINIX 3 tira proveito de três. Eles estão definidos simbolicamente nas 
linhas 5843 a 5845. As partes mais centrais do núcleo, as partes que são executadas durante as 
interrupções e que gerenciam as trocas de contexto, sempre são executadas com INTR PRI- 
VILEGE. Qualquer endereço na memória e qualquer registrador na CPU pode ser acessado 
por um processo com esse nível de privilégio. As tarefas são executadas no nível TASK PRI- 
VILEGE, o qual as permite acessar E/S, mas não usar instruções que modificam registradores 
especiais, como aqueles que apontam para tabelas de descritores. Os servidores e processos 
de usuário são executados no nível USER PRIVILEGE. Os processos em execução nesse 
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nível são incapazes de executar determinadas instruções; por exemplo, aquelas que acessam 
portas de E/S, alteram atribuições de memória ou alteram os próprios níveis de privilégio. 

O conceito de níveis de privilégio é familiar para aqueles que conhecem a arquitetura das 
CPUs modernas, mas quem tiver aprendido sobre arquitetura de computador estudando a lin- 
guagem assembly de microprocessadores baratos talvez não tenham encontrado tais recursos. 

Um arquivo de cabeçalho em kernel/ ainda não foi descrito: system.h. Deixaremos sua 
discussão para depois neste capítulo, quando descrevermos a tarefa de sistema, que é execu- 
tada como um processo independente, embora seja compilada com o núcleo. Por enquanto, 
terminamos com os arquivos de cabeçalho e estamos prontos para estudar os arquivos-fonte 
(*.c) da linguagem C. O primeiro deles que veremos é table.c (linha 6000). Sua compilação 
não produz código executável, mas o arquivo objeto table.o compilado conterá todas as es- 
truturas de dados do núcleo. Já vimos muitas dessas estruturas de dados definidas, em glo. 
h e em outros arquivos de cabeçalhos. Na linha 6028, é definida a macro TABLE, imediata- 
mente antes das instruções &include. Conforme explicado anteriormente, essa definição faz 
EXTERN ser definida como uma string nula e espaço de armazenamento ser alocado para 
todas as declarações de dados precedidas por EXTERN. 

Além das variáveis declaradas nos arquivos de cabeçalho, existem dois outros lugares 
onde o armazenamento de dados globais é alocado. Algumas definições são feitas direta- 
mente em table.c. Nas linhas 6037 a 6041, é definido o espaço de pilha necessário para os 
componentes do núcleo, e a quantidade total de espaço de pilha para tarefas é reservado como 
o array t stack/[TOT STACK SPACE], na linha 6045. 

O restante de table.c define muitas constantes relacionadas às propriedades dos proces- 
sos, como as combinações de bits de flag, chamadas de traps e máscaras que definem para 
quem podem ser enviadas as mensagens e notificações que vimos na Figura 2-35 (linhas 6048 
a 6071). Depois disso, encontramos as máscaras para definir as chamadas de núcleo permi- 
tidas para vários processos. O gerenciador de processos e o servidor de arquivos podem ter 
combinações únicas. O servidor de reencarnação pode acessar todas as chamadas de núcleo, 
não para seu próprio uso, mas porque, como pai de outros processos de sistema, ele só pode 
passar para seus filhos subconjuntos de seus próprios privilégios. Os drivers recebem um 
conjunto comum de máscaras de chamada do núcleo, exceto quanto ao driver de disco em 
RAM, que precisa de um tipo de acesso diferenciado à memória. (Note que o comentário 
na linha 6075 que cita o “gerenciador de serviços de sistema” deve mencionar “servidor de 
reencarnação” — o nome foi alterado durante o desenvolvimento e alguns comentários ainda 
se referem ao nome antigo.) 

Finalmente, nas linhas 6095 a 6109, é definida a tabela image. Ela foi colocada aqui e 
não em um arquivo de cabeçalho porque o truque usado com EXTERN para impedir declara- 
ções múltiplas não funciona com variáveis inicializadas; isto é, você não pode escrever 


extern int x = 3; 


em qualquer lugar. A tabela image fornece os detalhes necessários para inicializar todos os 
processos carregados na imagem de boot. Ela será usada pelo sistema na inicialização. Como 
exemplo das informações contidas aqui, considere o campo chamado qs no comentário da 
linha 6096. Isso mostra o tamanho do quantum atribuído para cada processo. Os processos de 
usuário normais, como filhos de init, podem ser executados por 8 tiques de relógio. As tarefas 
CLOCK e SYSTEM podem ser executadas por 64 tiques de relógio, se necessário. Na verda- 
de, não se espera que elas sejam executadas por tanto tempo antes de serem bloqueadas, mas, 
ao contrário dos servidores e drivers do espaço do usuário, elas não podem ser rebaixadas 
para uma fila de prioridade menor, caso impeçam que outros processos tenham a chance de 
executar. 
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2.6.6 


Se um novo processo precisar ser adicionado na imagem de boot, uma nova linha de- 
verá ser fornecida na tabela image. Um erro na correspondência do tamanho de image com 
outras constantes é intolerável e não pode ser permitido. No final de table.c são feitos testes 
para encontrar erros, usando um pequeno truque. O array dummy é declarado duas vezes. 
Caso se cometa algum engano, um tamanho impossível (negativo) será atribuído para dummy 
e provocará um erro de compilação. Como dummy é declarado como extern, nenhum espaço 
é alocado para ele aqui (nem em nenhum lugar). Não sendo referenciado em nenhum outro 
lugar no código, isso não incomodará o compilador. 

Um armazenamento global adicional é alocado no final do arquivo em linguagem as- 
sembly mpx386.s. Embora seja necessário pular várias páginas adiante na listagem para ver 
isso, é apropriado discutir agora, pois estamos no assunto das variáveis globais. Na linha 
6822, a diretiva de montador .sect .rom é usada para colocar um número mágico (para iden- 
tificar um núcleo válido do MINIX 3) bem no início do segmento de dados do núcleo. A dire- 
tiva de montador .sect bss e a pseudo-instrução .space também são usadas aqui para reservar 
espaço para a pilha do núcleo. A pseudo-instrução .comm rotula várias palavras no início da 
pilha para que elas possam ser manipuladas diretamente. Voltaremos ao arquivo mpx386.s em 
breve, após termos discutido a inicialização do MINIX 3. 


Inicialização do MINIX 3 


Quase já dá para começarmos a ver o código executável — mas ainda não. Antes disso, dedica- 
remos alguns instantes para entendermos como o MINIX 3 é carregado na memória. É claro 
que ele é carregado a partir de um disco, mas o processo não é completamente simples e a 
sequência exata dos eventos depende do tipo de disco. Em particular, ela depende de o disco 
estar particionado ou não. A Figura 2-36 mostra como disquetes e discos particionados são 
organizados. 

Quando o sistema é iniciado, o hardware (na verdade, um programa na memória ROM) 
lê o primeiro setor do disco de boot, copia-o em um local fixo na memória e executa o código 
encontrado lá. Em um disquete MINIX 3, o primeiro setor é um bloco de boot (bootblock) 


(a) (b) 


Figura 2-36 Estruturas de disco usadas na inicialização (bootstrapping). (a) Disco não par- 
ticionado. O primeiro setor é o bloco de boot. (b) Disco particionado. O primeiro setor é o 
registro de boot mestre, também chamado de masterboot. 
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que carrega o programa de boot, como se vê na Figura 2-36(a). Já os discos rígidos normal- 
mente possuem várias partições e o programa presente no primeiro setor (chamado de mas- 
terboot nos sistemas MINIX) é copiado para a memória e, em seguida, quando executado, lê 
a tabela de partição, existente junto com ele a partir do primeiro setor. Então, ele carrega na 
memória e executa o primeiro setor da partição marcada como ativa, como mostra a Figura 
2-36(b). (Normalmente, uma e apenas uma partição é marcada como ativa). Uma partição do 
MINIX 3 tem a mesma estrutura de um disquete MINIX 3, com um bloco de boot que possui 
um programa de boot. O código do bloco de boot é o mesmo para um disco que possui e que 
não possui partições. 

A situação real pode ser um pouco mais complicada do que a figura mostra, pois uma 
partição pode conter subpartições. Nesse caso, o primeiro setor da partição será outro registro 
de boot mestre, contendo a tabela de partição das subpartições. Finalmente, entretanto, o con- 
trole será passado para um setor de boot, o primeiro setor em um dispositivo que não tenha 
mais subdivisões. Em um disquete, o primeiro setor é sempre um setor de boot. O MINIX 3 
permite uma forma de particionamento de um disquete, mas apenas a primeira partição pode 
ser usada para boot; não há nenhum registro de boot mestre separado e subpartições não são 
possíveis. Isso possibilita que disquetes particionados e não particionados sejam montados 
(mount) e desmontados (umount) da mesma maneira. A principal utilidade de um disquete 
particionado é que ele proporciona uma maneira conveniente de dividir um disco de instala- 
ção em uma imagem-raiz a ser copiada em um disco em RAM e uma parte montada que pode 
ser desmontada quando não for mais necessária, liberando a unidade de disquete na continu- 
ação do processo de instalação. 

O setor de boot do MINIX 3 é modificado no momento em que é escrito no disco, por 
um programa especial chamado installboot, o qual atualiza um arquivo especial chamado 
boot de sua partição ou subpartição. No MINIX 3, a localização padrão do programa boot é 
em um diretório de mesmo nome; isto é, /boot/boot. Mas poderia ser em qualquer lugar — a 
modificação do setor de boot que acabamos de mencionar determina os setores de disco a 
partir dos quais deve ser carregado. Isso é necessário porque, antes de carregar o programa 
boot lá, não há como usar nomes de diretório e arquivo para localizar um arquivo. 

O programa boot é o carregador secundário do MINIX 3. Entretanto, ele pode fazer 
mais do que apenas carregar o sistema operacional, pois é um programa monitor que per- 
mite ao usuário alterar, configurar e salvar diversos parâmetros. O programa boot examina 
o segundo setor de sua partição para localizar um conjunto de parâmetros para utilizar. O 
MINIX 3, assim como o UNIX padrão, reserva o primeiro bloco de 1K de cada dispositivo de 
disco como bloco de boot, mas apenas um setor de 512 bytes é lido pelo carregador de boot 
da memória ROM ou pelo setor de boot mestre, de modo existem 512 bytes disponíveis para 
salvar configurações. Isso controla a operação de boot e também é passado para o sistema 
operacional em si. As configurações padrão apresentam um menu com uma opção, iniciar o 
MINIX 3, mas as configurações podem ser modificadas para apresentar um menu mais com- 
plexo, permitindo o boot de outros sistemas operacionais (carregando e executando setores de 
boot de outras partições) ou iniciar o MINIX 3 com várias opções. As configurações padrão 
também podem ser modificadas para ignorar o menu e iniciar o MINIX 3 imediatamente. 

O programa boot não faz parte do sistema operacional, mas é inteligente o bastante para 
usar as estruturas de dados do sistema de arquivos para encontrar a imagem real do sistema 
operacional. O programa boot procura um arquivo com o nome especificado no parâmetro 
image=, o qual, por padrão, é /boot/image. Se houver um arquivo normal com esse nome, ele 
será carregado, mas se esse for o nome de um diretório, o arquivo mais recente dentro dele 
será carregado. Muitos sistemas operacionais têm um nome de arquivo pré-definido para a 
imagem de boot, mas os usuários do MINIX 3 devem modificá-lo ao criar novas versões. É 
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útil poder escolher uma entre várias versões, para voltar a uma versão antiga, caso uma expe- 
riência seja mal-sucedida. 

Não temos espaço aqui para detalhar sobre o monitor de boot. Ele é um programa so- 
fisticado, quase um sistema operacional em miniatura propriamente dito. Ele trabalha junto 
com o MINIX 3 e quando o MINIX 3 é desligado corretamente, o monitor de boot retoma o 
controle. Se quiser saber mais, o site web do MINIX 3 fornece um [ink para uma descrição 
detalhada do código-fonte do monitor de boot. 

A imagem de boot (também chamada de imagem de sistema) do MINIX 3 é uma con- 
catenação de vários arquivos de programa: o núcleo, o gerenciador de processos, o sistema de 
arquivos, o servidor de reencarnação, diversos drivers de dispositivo e init, como mostrado na 
Figura 2-30. Note que o MINIX 3, conforme descrito aqui, é configurado com apenas um dri- 
ver de disco na imagem de boot, mas diversos podem estar presentes, com o driver ativo sele- 
cionado por um rótulo. Assim como em todos os programas binários, cada arquivo na imagem 
de boot inclui um cabeçalho que informa quanto se deve reservar de espaço para dados não 
inicializados e para a pilha, após carregar o código executável e os dados inicializados. Isso é 
necessário para que o próximo programa possa ser carregado no endereço correto. 

As regiões da memória disponíveis para carregar o monitor de boot e os programas 
componentes do MINIX 3 dependerão do hardware. Além disso, algumas arquiteturas podem 
exigir ajuste dos endereços internos do código executável para corrigi-los com o endereço 
real onde um programa é carregado (esse ajuste é denominado de relocação). A gerência de 
memória, em hardware, dos processadores Intel torna isso desnecessário. 

Os detalhes do processo de carga diferem com o tipo de máquina. O importante é que, 
por um meio ou outro, o sistema operacional é carregado na memória. Depois disso, é exigida 
uma pequena quantidade de preparação antes que o MINIX 3 possa ser iniciado. Primeira- 
mente, ao carregar a imagem, o programa boot lê alguns bytes da imagem que informam 
algumas de suas propriedades, principalmente se ela foi compilada para execução no modo 
de 16 ou de 32 bits. Então, algumas informações adicionais necessárias para iniciar o sistema 
se tornam disponíveis para o núcleo. Os cabeçalhos a.out dos componentes da imagem do 
MINIX 3 são extraídos para um array dentro do espaço de memória do programa boot e o en- 
dereço de base desse array é passado para o núcleo. Ao terminar, o MINIX 3 pode retornar o 
controle para o monitor de boot, para que também seja passado o local onde a execução deve 
ser retomada no monitor. Esses itens são passados na pilha, conforme veremos depois. 

Várias outras informações, os parâmetros de inicialização, devem ser comunicadas do 
monitor de boot para o sistema operacional. Algumas são necessárias para o núcleo e outras 
não, mas são passadas apenas para conhecimento; por exemplo, o nome da imagem de boot 
que foi carregada. Todos esses itens podem ser representados como pares string=valor e o 
endereço de uma tabela desses pares é passado na pilha. A Figura 2-37 mostra um conjunto 
de parâmetros de boot típico, conforme exibido pelo comando sysenv a partir da linha de 
comando do MINIX 3. 

Nesse exemplo, um item importante que logo veremos outra vez é o parâmetro memory; 
neste caso, ele indica que o monitor de boot determinou que existem dois segmentos de 
memória disponíveis para o MINIX 3 usar. Um deles começa no endereço hexadecimal 800 
(decimal 2048) e tem um tamanho de 0x92540 hexadecimal (decimal 599.360) bytes; o outro 
começa em 100000 (1.048.576) e contém 0x3df00000 (64.946.176) bytes. Isso é típico de 
todos os computadores compatíveis com PC, a não ser pelos mais antigos. O projeto do IBM 
PC original colocou a memória somente de leitura no topo do intervalo de memória utilizável, 
que é limitado em 1 MB em uma CPU 8088. As máquinas modernas, compatíveis com o PC, 
sempre têm mais memória do que o PC original, mas, por compatibilidade, elas ainda têm a 
memória somente de leitura nos mesmos endereços das máquinas mais antigas. Assim, a me- 
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2.6.7 


rootdev=904 
ramimagedev=904 
ramsize=0 
processor=686 
bus=at 

video=vga 
chrome=color 
memory=800:92540,100000:3DF0000 
label=AT 
controller=cO 
image=boot/image 


Figura 2-37 Parâmetros de boot passados para o núcleo no momento da inicialização de um 
sistema MINIX 3 típico. 


mória de leitura e escrita é não-contígua, com um bloco de memória ROM entre os 640 KB 
inferiores e o intervalo superior acima de 1 MB. O monitor de boot carrega o núcleo no inter- 
valo de memória baixa e os servidores, drivers e init, no intervalo de memória acima da me- 
mória ROM, se possível. Isso serve principalmente para proveito do sistema de arquivos, para 
que possa ser usada uma cache de blocos grande sem ser confinada pela memória ROM. 

Também devemos mencionar aqui que os sistemas operacionais não são universalmente 
carregados a partir de discos locais. Estações de trabalho sem disco (diskless) podem car- 
regar seus sistemas operacionais a partir de um disco remoto, por meio de uma conexão de 
rede. É claro que isso exige software de rede na memória ROM. Embora os detalhes variem 
em relação ao que descrevemos aqui, os elementos do processo provavelmente são seme- 
lhantes. O código da memória ROM deve ser inteligente o suficiente para obter um arquivo 
executável pela rede, que pode então obter o sistema operacional completo. Se o MINIX 3 
fosse carregado dessa maneira, muito pouco precisaria ser alterado no processo de boot que 
ocorre quando o código do sistema operacional é carregado na memória. Seriam necessários, 
é claro, um servidor de rede e um sistema de arquivos modificado que pudesse acessar arqui- 
vos por meio da rede. 


Inicialização do sistema 


As versões anteriores do MINIX podiam ser compiladas no modo de 16 bits, caso fosse exi- 
gida compatibilidade com processadores mais antigos, e o MINIX 3 mantém algum código- 
fonte para o modo de 16 bits. Entretanto, a versão descrita aqui, e distribuída no CD-ROM, só 
serve para máquinas de 32 bits com processadores 80386 ou mais recentes. Ela não funciona 
no modo de 16 bits e a criação de uma versão de 16 bits pode exigir a retirada de alguns recur- 
sos. Dentre outras coisas, os binários de 32 bits são maiores do que os de 16 bits e os drivers 
em espaço de usuário independentes não podem compartilhar código, como podia ser feito 
quando os drivers eram compilados em um único binário. Contudo, é usada uma base comum 
de código-fonte em C e o compilador gera a saída apropriada, dependendo de o compilador 
em si ser da versão de 16 ou de 32 bits. Uma macro definida pelo próprio compilador deter- 
mina a definição da macro WORD SIZE no arquivo include/minix/sys  config.h. 

A primeira parte do MINIX 3 a executar foi escrita em linguagem assembly e diferentes 
arquivos de código-fonte devem ser usados para o compilador de 16 ou 32 bits. A versão de 
32 bits do código de boot está em mpx386.s. A versão alternativa, para sistemas de 16 bits, 
está em mpx88.s. As duas versões também incluem suporte em linguagem assembly para 
outras operações de baixo nível do núcleo. A seleção é feita automaticamente em mpx.s. Esse 
arquivo é tão pequeno que pode ser apresentado por inteiro na Figura 2-38. 
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Hinclude <minix/config.h> 
Hif WORD SIZE == 
Hinclude “mpx88.s” 

telse 

Hinclude “mpx386.s” 
Hendif 


Figura 2-38 Como os arquivos-fonte, em linguagem assembly alternativos, são selecio- 
nados. 


O arquivo mpx.s mostra um uso incomum da instrução finclude do pré-processador 
C. Normalmente, a diretiva de pré-processador &include é utilizada para incluir arquivos de 
cabeçalho, mas também pode ser usada para selecionar uma seção alternativa de código-fon- 
te. Usar instruções #if para fazer isso exigiria colocar todo o código dos arquivos mpx88.s e 
mpx386.s em um único arquivo. Isso não apenas seria complicado, como também desperdi- 
çaria espaço em disco, pois em uma instalação em particular é provável que um desses dois 
arquivos nem mesmo seja usado e possa ser colocado em um repositório ou excluído. Na 
discussão a seguir, utilizaremos os arquivo mpx386.s de 32 bits. 

Como este é praticamente nosso primeiro estudo de código executável, vamos começar 
com algumas palavras sobre como faremos isso em todo o livro. Os vários arquivos-fonte uti- 
lizados na compilação de um programa em C grande podem ser difíceis de acompanhar. Em 
geral, manteremos as discussões restritas a um único arquivo por vez. A ordem de inclusão 
dos arquivos no Apêndice B é aquela em que os discutimos no texto. Começaremos com o 
ponto de entrada de cada parte do sistema MINIX 3 e seguiremos a linha de execução princi- 
pal. Quando for encontrada uma chamada para uma função de suporte, diremos algumas pa- 
lavras sobre o objetivo da chamada, mas nesse ponto, normalmente não entraremos em uma 
descrição detalhada dos aspectos internos da função, deixando isso para quando chegarmos 
à sua definição. Normalmente, funções subordinadas importantes são definidas no mesmo 
arquivo em que são chamadas, após as funções de chamada de nível mais alto, mas as funções 
pequenas, ou de propósito geral, às vezes são reunidas em arquivos separados. Não tentamos 
discutir os aspectos internos de cada função e os arquivos que contêm tais funções podem não 
estar listados no Apêndice B. 

Para facilitar a portabilidade para outras plataformas, frequentemente são usados ar- 
quivos separados para código dependente e independente de máquina. Para tornar o código 
mais fácil de entender e reduzir o tamanho global das listagens, a maior parte do código con- 
dicional para plataformas que não sejam os sistemas Intel de 32 bits foi retirada dos arquivos 
impressos no Apêndice B. Versões completas de todos os arquivos estão nos diretórios fonte 
do CD-ROM e também estão disponíveis no site web do MINIX 3. 

Esforçamos-nos ao máximo para tornar o código legível para seres humanos. Mas um 
programa grande tem muitos desvios e, às vezes, o entendimento de uma função principal 
exige a leitura da função que a chama; portanto, às vezes pode ser útil ter algumas tiras de 
papel para usar como marcadores e desviar da ordem de nossa discussão para ver as coisas 
em uma segiiência diferente. 

Tendo exposto nossa maneira de organizar a discussão sobre o código, começaremos 
com uma exceção. A inicialização do MINIX 3 envolve várias transferências de controle 
entre as rotinas em linguagem assembly presentes em mpx386.s e as rotinas em linguagem C 
presentes nos arquivos start.c e main.c. Descreveremos essas rotinas na ordem em que elas 
são executadas, mesmo que isso envolva pular de um arquivo para outro. 

Quando o processo de inicialização tiver carregado o sistema operacional na memória, 
o controle será transferido para o rótulo MINIX (em mpx386.s, linha 6420). A primeira ins- 
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trução é um salto sobre alguns bytes de dados; isso inclui os flags do monitor de inicialização 
(linha 6423) mencionados anteriormente. Neste ponto, os flags já cumpriram seu objetivo; 
eles foram lidos pelo monitor quando este carregou o núcleo na memória. Eles ficam aqui 
porque esse é um endereço facilmente especificado. Os flags são usados pelo monitor de boot 
para identificar diversas características do núcleo, principalmente se o sistema é de 16 ou de 
32 bits. O monitor de boot sempre começa no modo de 16 bits, mas, se necessário, troca a 
CPU para o modo de 32 bits. Isso acontece antes que o controle passe para o rótulo MINIX. 

Entender o estado da pilha neste ponto ajudará a compreender o código seguinte. O 
monitor passa vários parâmetros para o MINIX 3, colocando-os na pilha. Primeiro, o monitor 
extrai o endereço da variável aout, a qual contém o endereço de um array das informações de 
cabeçalho dos programas componentes da imagem de boot. Em seguida, ele extrai o tamanho 
e, então, o endereço dos parâmetros de inicialização. Todos esses são valores de 32 bits. Em 
seguida, vem o endereço do segmento de código do monitor e a localização para retornar para 
dentro do monitor quando o MINIX 3 terminar. Ambos são valores de 16 bits, pois o moni- 
tor opera no modo protegido de 16 bits. As primeiras instruções em mpx366.s convertem o 
ponteiro da pilha de 16 bits, utilizado pelo monitor, em um valor de 32 bits para uso no modo 
protegido. Então, a instrução 


mov ebp, esp 


(linha 6436) copia o valor do ponteiro da pilha no registrador ebp, para que ele possa ser 
usado com deslocamentos para recuperar da pilha os valores lá colocados pelo monitor, como 
acontece nas linhas 6464 a 6467. Note que, como a pilha cresce para baixo nos processadores 
Intel, 8(ebp) se refere a um valor colocado após a extração do valor localizado em 12(ebp). 

O código em linguagem assembly deve realizar um grande volume de trabalho, confi- 
gurando uma estrutura de pilha para fornecer o ambiente correto para o código gerado pelo 
compilador C, copiando as tabelas usadas pelo processador para definir segmentos de me- 
mória e configurando vários registradores do processador. Assim que esse trabalho termina, 
o processo de inicialização continua, chamando (na linha 6481) a função C cstart (em start. 
c, que consideraremos a seguir). Note que essa função é referida como cstart no código 
em linguagem assembly. Isso acontece porque todas as funções compiladas pelo compilador 
C têm um sublinhado anexado no início de seus nomes nas tabelas de símbolo e o ligador 
(linker) procura esses nomes quando módulos compilados separadamente são ligados. Como 
o montador não adiciona automaticamente os sublinhados, o desenvolvedor de um programa 
em linguagem assembly deve adicioná-los explicitamente para que o ligador possa encontrar 
um nome correspondente no arquivo objeto compilado pelo compilador C. 

Cstart chama outra rotina para inicializar a Tabela Global de Descritores (Global 
Descriptor Table — GDT), a estrutura de dados central utilizada pelos processadores Intel de 
32 bits para supervisionar a proteção da memória, e a Tabela de Descritores de Interrupção 
(Interrupt Descriptor Table — IDT), empregada para determinar o código a ser executado 
para cada tipo de interrupção possível. Ao retornar de cstart, as instruções Igat e lidt (linhas 
6487 e 6488) fazem essas tabelas entrarem em vigor, carregando os registradores dedicados 
por meio do quais são endereçadas. À primeira vista, a instrução 


jmpf CS SELECTOR:csinit 


não parece uma operação, pois ela transfere o controle exatamente para onde ele estaria se 
houvesse uma série de instruções nop em seu lugar. Mas essa é uma parte importante do 
processo de inicialização. Esse salto impõe o uso das estruturas que acabaram de ser iniciali- 
zadas. Após mais alguma manipulação dos registradores do processador, MINIX termina com 
um desvio (e não com uma chamada), na linha 6503, para o ponto de entrada main do núcleo 
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(em main.c). Neste ponto, o código de inicialização em mpx386.s está terminado. O restante 
do arquivo contém código para iniciar ou reiniciar uma tarefa ou processo, rotinas de trata- 
mento de interrupção e outras rotinas de suporte que, por eficiência, tiveram de ser escritas 
em linguagem assembly. Voltaremos a elas na próxima seção. 

Veremos agora as funções de inicialização de alto nível em C. A estratégia geral é fa- 
zer o máximo possível usando código de alto nível em C. Conforme vimos, já existem duas 
versões do código mpx. Um trecho de código C pode eliminar dois trechos de código do 
montador. Praticamente, a primeira coisa feita por cstart (em start.c, linha 6920) é configurar 
os mecanismos de proteção da CPU e as tabelas de interrupção, chamando prot init. Em se- 
guida, ela copia os parâmetros de boot para a memória do núcleo e os percorre, usando a fun- 
ção get value (linha 6997), para procurar nomes de parâmetro e retornar as strings de valor 
correspondentes. Esse processo determina o tipo de exibição de vídeo, o tipo de processador, 
o tipo de barramento e, caso esteja no modo de 16 bits, o modo de operação do processador 
(real ou protegido). Todas essas informações são armazenadas em variáveis globais para aces- 
so, quando necessário, por qualquer parte do código do núcleo. 

Main (em main.c, linha 7130), completa a inicialização e depois inicia a execução nor- 
mal do sistema. Esse arquivo configura o hardware de controle de interrupção, chamando 
intr init. Isso é feito aqui porque não pode ser feito até que o tipo de máquina seja conhecido. 
(Como intr init depende muito do hardware, a função está em um arquivo separado que será 
descrito posteriormente.) O parâmetro (1) na chamada informa a intr init que está iniciali- 
zando para o MINIX 3. Com o parâmetro (0), ela pode ser chamada para reinicializar o har- 
dware no estado original quando o MINIX 3 terminar e retornar o controle para o monitor de 
boot. Intr init garante que as interrupções ocorridas antes que a inicialização esteja concluída 
não tenham nenhum efeito. O modo como isso é feito será descrito posteriormente. 

A maior parte do código de main é dedicada à configuração da tabela de processos e da 
tabela de privilégios, para que, quando as primeiras tarefas e processos tiverem sua execução 
programada, seus mapas de memória, registradores e informações de privilégio estejam cor- 
retamente configurados. Todas as entradas da tabela de processos são marcadas como livres 
e o array pproc addr que acelera o acesso à tabela de processos é inicializado pelo laço nas 
linhas 7150 a 7154. O laço nas linhas 7155 a 7159 limpa a tabela de privilégios e o mesmo 
acontece para a tabela de processos com o array ppriv addr e seu array de acesso. Tanto para 
as tabelas de processos, como para a tabela de privilégios, é adequado colocar um valor es- 
pecífico em um campo para marcar a entrada como não utilizada. Mas para cada tabela, toda 
entrada, esteja em uso ou não, precisa ser inicializada com um número de índice. 

Uma nota sobre uma característica secundária da linguagem C: o código da linha 7153 


(pproc addr + NR TASKSJfi] = rp; 
também poderia ser escrito como 
pproc addrfi + NR TASKS] = rp; 


Na linguagem C, a[i] é apenas outra maneira de escrever *(a-+i). Portanto, não faz muita 
diferença se você somar uma constante a a ou a i. Alguns compiladores C geram um código 
ligeiramente melhor se você somar uma constante ao array, em vez do índice. Não podemos 
dizer se isso realmente faz diferença aqui. 

Chegamos agora no longo laço das linhas 7172 a 7242, que inicializa a tabela de pro- 
cessos com as informações necessárias para executar todos os processos da imagem de boot. 
(Note que há outro comentário obsoleto na linha 7161, que menciona apenas tarefas e servi- 
dores.) Todos esses processos devem estar presentes no momento da inicialização e nenhum 
terminará durante a operação normal. No início do laço, ip recebe o endereço de uma entrada 
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na tabela image criada em table.c (linha 7173). Como ip é um ponteiro para uma estrutura, 
os elementos da estrutura podem ser acessados usando-se uma notação como ip->proc nr, 
como foi feito na linha 7174. Essa notação é usada extensivamente no código-fonte do MI- 
NIX 3. De maneira semelhante, rp é um ponteiro para uma entrada da tabela de processos e 
priv(rp) aponta para uma entrada da tabela de privilégios. Grande parte da inicialização das 
tabelas de processos e de privilégios no laço longo consiste em ler um valor da tabela de ima- 
gem e armazená-lo na tabela de processos ou na tabela de privilégios. 

Na linha 7185 é feito um teste para os processos que fazem parte do núcleo e, se ele der 
resultado positivo, o padrão especial STACK GUARD será armazenado na base da área de 
pilha da tarefa. Isso pode ser verificado posteriormente, para garantir que a pilha não estoure. 
Então, o ponteiro de pilha inicial de cada tarefa é configurado. Cada tarefa precisa de seu 
próprio ponteiro de pilha privado. Como a pilha cresce em direção aos endereços mais baixos 
na memória, o ponteiro de pilha inicial é calculado pela adição do tamanho da pilha da tarefa 
ao endereço de base corrente (linhas 7190 e 7191). Existe uma exceção: o processo KERNEL 
(também identificado como HARDWARE em alguns lugares) nunca é considerado pronto, 
nunca é executado como um processo normal e, assim, não precisa de um ponteiro de pilha. 

Os binários dos componentes da imagem de boot são compilados como todos os 
outros programas do MINIX 3 e o compilador cria um cabeçalho, conforme definido em 
include/a.out.h, no início de cada um dos arquivos. O carregador de boot copia cada um 
desses cabeçalhos em seu próprio espaço de memória, antes que o MINIX 3 comece, e 
quando o monitor transfere o controle para o ponto de entrada MINIX: em mpx386.s, o en- 
dereço físico da área de cabeçalho é passado para o código assembly na pilha, conforme já 
vimos. Na linha 7202, um desses cabeçalhos é copiado em uma estrutura exec local, ehdr, 
usando hdrindex como índice para o array de cabeçalhos. Então, os dados e os endereços 
do segmento de texto são convertidos em clicks (unidade de gerência de memória do MI- 
NIX) e inseridos no mapa de memória desse processo (linhas 7205 a 7214). 

Antes de continuarmos, devemos mencionar alguns pontos. Primeiramente, para os 
processos do núcleo, hdrindex sempre recebe um valor igual à zero, na linha 7178. Todos 
esses processos são compilados no mesmo arquivo que o núcleo e as informações sobre seus 
requisitos de pilha estão na tabela image. Como uma tarefa compilada no núcleo pode chamar 
código e acessar dados localizados em qualquer parte no espaço do núcleo, o tamanho de uma 
tarefa individual não é significativo. Assim, o mesmo elemento do array em aout é acessado 
para o núcleo e para cada tarefa, e os campos de tamanho de uma tarefa são preenchidos 
com os tamanhos do próprio núcleo. As tarefas recebem suas informações de pilha da tabela 
image, inicializada durante a compilação de table.c. Depois que todos os processos do núcleo 
tiverem sido processados, hdrindex é incrementado em cada passagem pelo laço (linha 7196); 
portanto, todos os processos de sistema do espaço do usuário recebem os dados corretos de 
seus próprios cabeçalhos. 

Outro ponto a mencionar aqui é que as funções que copiam dados não são necessa- 
riamente consistentes em relação à ordem em que a origem e o destino são especificados. 
Ao ler esse laço, tenha cuidado com a confusão em potencial. Os argumentos de strncpy, 
uma função da biblioteca C padrão, são ordenados de maneira que o destino vem primeiro: 
strncpy(to, from, count). Isso é parecido com uma operação de atribuição, na qual o lado 
esquerdo especifica a variável que está recebendo a atribuição e o lado direito é a expressão 
que especifica o valor a ser atribuído. Essa função é usada na linha 7179 para copiar um 
nome de processo em cada entrada da tabela de processos para depuração e outros propó- 
sitos. Em contraste, a função phys. copy utiliza uma convenção oposta, phys copy(from, to, 
quantity). Phys. copy é usada na linha 7202 para copiar cabeçalhos de programa de processos 
do espaço do usuário. 
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Continuando nossa discussão sobre a inicialização da tabela de processos, nas linhas 
7220 e 7221 são configurados o valor inicial do contador de programa e a palavra de status 
do processador. A palavra de status do processador para as tarefas é diferente da palavra para 
drivers de dispositivo e servidores, pois as tarefas têm um nível de privilégio mais alto que 
permite acessar portas de E/S. Depois disso, se o processo for em espaço de usuário, seu pon- 
teiro de pilha será inicializado. 

Uma entrada na tabela de processos não precisa (e não pode) ter sua execução escalona- 
da. O processo HARDWARE existe apenas para propósitos de contabilidade — ele é creditado 
com o tempo usado para atender uma interrupção. Todos os outros processos são colocados 
nas filas apropriadas pelo código das linhas 7234 e 7235. A função chamada lock engueue 
desabilita as interrupções, antes de modificar as filas, e depois as habilita novamente, quando 
a fila tiver sido modificada. Isso não é obrigatório neste ponto, quando nada ainda está em 
execução, mas é o método padrão e não há porque criar código extra para ser usado apenas 
uma vez. 

A última etapa na inicialização de cada entrada na tabela de processos é chamar a fun- 
ção alloc segments, na linha 7241. Essa rotina dependente de arquitetura inicializa, nos cam- 
pos adequados, as localizações, os tamanhos e os níveis de permissão para os segmentos de 
memória utilizados por cada processo. Para os processadores Intel mais antigos, que não su- 
portam o modo protegido, ela define apenas as localizações do segmento. Em um processador 
com um método diferente de alocação de memória essa rotina precisa ser reescrita. 

Uma vez que a tabela de processos foi inicializada para todas as tarefas, para os servi- 
dores e init, o sistema estará quase pronto para funcionar. A variável bill ptr identifica qual 
processo é cobrado pelo tempo do processador; ela precisa ter um valor inicial configurado na 
linha 7250 e, claramente, IDLE é uma escolha apropriada. Agora, o núcleo está pronto para 
iniciar seu trabalho normal de controle e escalonamento dos processos, conforme ilustrado 
na Figura 2-2. 

Nem todas as outras partes do sistema já estão prontas para a operação normal, mas 
todas essas partes são executadas como processos independentes e foram marcadas como 
prontas e enfileiradas para executar. Elas se inicializarão sozinhas, quando executadas. Resta 
apenas o núcleo chamar announce para anunciar que está pronto e depois restart (linhas 7251 
e 7252). Em muitos programas em C, main é um laço, mas no núcleo do MINIX 3 sua tarefa 
é realizada quando a inicialização está concluída. A chamada de restart, na linha 7252, inicia 
o primeiro processo enfileirado. O controle nunca retorna para main. 

“Restart é uma rotina em linguagem assembly presente em mpx386.s. Na verdade, res- 
tart não é uma função completa; trata-se de um ponto de entrada intermediário em uma fun- 
ção maior. Vamos discuti-la em detalhes na próxima seção; por enquanto, diremos apenas que 
_restart causa uma troca de contexto para que o processo apontado por proc ptr seja executa- 
do. Quando restart tiver sido executada pela primeira vez, poderemos dizer que o MINIX 3 
está funcionando — ele estará executando um processo. Restart é executada repetidamente, à 
medida que tarefas, servidores e processos de usuário tenham sua oportunidade de executar e 
então sejam suspensos, ou para esperar entrada ou para dar a vez para outros processos. 

É claro que na primeira vez que _restart é executada, a inicialização está concluída 
apenas para o núcleo. Lembre-se de que existem três partes na tabela de processos do MINIX 
3. Você poderia perguntar como é que processos podem ser executados quando partes impor- 
tantes da tabela de processos ainda não foram configuradas. A resposta completa disso será 
dada em capítulos posteriores. A resposta curta é que os ponteiros de instrução de todos os 
processos na imagem de boot apontam inicialmente para o código de inicialização de cada 
processo e todos serão bloqueados muito em breve. Finalmente, o gerenciador de processos 
e o sistema de arquivos executarão seu código de inicialização e suas partes da tabela de 
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2.6.8 


processos serão completadas. Por fim, init criará um processo getty para cada terminal. Esses 
processos serão bloqueados até que uma entrada seja digitada em algum terminal, momento 
este em que o primeiro usuário poderá se conectar. 

Acabamos de acompanhar a inicialização do MINIX 3 por meio de três arquivos, dois 
escritos em C e um em linguagem assembly. O arquivo em linguagem assembly, mpx366.s, 
contém código adicional utilizado no tratamento de interrupções, o que veremos na próxima 
seção. Entretanto, antes de prosseguirmos, vamos encerrar esta parte com uma breve descri- 
ção das rotinas restantes nos dois arquivos em C. A função restante em start.c é get value 
(linha 6997). Ela é usada para localizar entradas no ambiente do núcleo, que é uma cópia dos 
parâmetros de inicialização. Trata-se de uma versão simplificada de uma função de biblioteca 
padrão, reescrita aqui para manter o núcleo simples. 

Existe mais três funções em main.c. Announce exibe uma nota de copyright e informa 
se o MINIX 3 está sendo executado no modo real ou no modo protegido de 16 ou de 32 bits, 
como segue: 


MINIX 3.1 Copyright 2006 Vrije Universiteit, Amsterdam, The Netherlands 
Executing in 32-bits protected mode 


Quando você vir essa mensagem, saberá que a inicialização do núcleo está termina- 
da. Prepare shutdown (linha 7272) sinaliza todos os processos de sistema com um sinal 
SIGKSTOP (os processos de sistema não podem ser sinalizados da mesma maneira que os 
processos de usuário). Então, ela configura um temporizador para dar tempo a todos os pro- 
cessos de sistema para fazer a limpeza, antes de chamar a última função, aqui, shutdown. 
Normalmente, shutdown retornará o controle para o monitor de boot do MINIX 3. Para isso, 
os controladores de interrupção são restaurados com as configurações da BIOS pela chamada 
de intr init(0), na linha 7338. 


Tratamento de interrupção no MINIX 


Os detalhes do hardware de interrupção dependem do sistema, mas todo sistema deve ter 
elementos funcionalmente equivalentes àqueles aqui descritos para sistemas com CPUs Intel 
de 32 bits. As interrupções geradas pelos dispositivos de hardware são sinais elétricos ma- 
nipulados primeiramente por um controlador de interrupção, um circuito integrado capaz 
de detectar diversos desses sinais e, para cada um, gerar um padrão de dados exclusivo no 
barramento de dados do processador. Isso é necessário porque fisicamente o processador tem 
apenas um pino para receber pedidos de interrupções e, assim, não consegue diferenciar qual 
dispositivo precisa de atendimento. Normalmente, os PCs que utilizam processadores Intel 
de 32 bits são equipados com dois desses chips controladores. Cada um pode manipular oito 
entradas, mas um deles é usado como controlador-escravo gerando um único sinal de inter- 
rupção que é enviado à entrada do controlador usado como mestre; portanto, 15 dispositivos 
externos distintos podem ser detectados pela combinação de ambos controladores, como se 
vê na Figura 2-39. Algumas das 15 entradas são dedicadas; por exemplo, a entrada de relógio, 
IRQO (Interrupt ReQuest), não está associada a nenhum conector (slot) onde um novo dispo- 
sitivo possa ser posto. As interrupções que são vinculadas a conectores podem ser usadas por 
qualquer dispositivo neles inseridos. 

Na figura, os sinais de interrupção chegam às diversas linhas IRQ n mostradas à direita. 
A conexão com o pino INT da CPU informa ao processador que ocorreu uma interrupção. O 
sinal INTA (reconhecimento de interrupção) da CPU faz com que o controlador responsável 
pela interrupção coloque no barramento de dados do sistema uma informação que diga ao 
processador qual rotina de tratamento de interrupção deve ser executada. Os chips controla- 
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IRQ O (relógio) 
IRQ 1 (teclado) 
IRQ 3 (tty 2) 
— de IRQ 4 (tty 1) 
interrupção IRQ 5 esa XT) 
mestre IRQ 6 (disquete) 
ACK IRQ 7 (impressora) 


Reconhe- 


cimento de -—— IRQ 8 (relógio de tempo real) 


interrupção ——— IRQ 9 (IRQ 2 redirecionado) 
Controlador |«—— IRQ 10 
IRQ 11 
interrupção IRQ 12 
escravo IRQ 13 (exceção de FPU) 
ACK IRQ 14 (Winchester AT) 


e IRQ 15 


n30-0v-y oa voaa v00o-3039=4+90o 


Figura 2-39 Hardware de processamento de interrupção em um PC Intel de 32 bits. 


dores de interrupção são programados durante a inicialização do sistema, quando main chama 
intr init. A programação determina o que é enviada para a CPU quando um sinal de inter- 
rupção é recebido em cada uma das linhas de entrada, assim como vários outros parâmetros 
de operação do controlador. A informação colocada no barramento é um número de 8 bits, 
usado para indexar uma tabela de até 256 elementos. A tabela do MINIX 3 tem 56 elementos. 
Desses, 35 são realmente usados; os outros estão reservados para uso em novas gerações de 
processadores Intel ou para aprimoramentos futuros do MINIX 3. Nos processadores Intel de 
32 bits, essa tabela contém descritores de interrupção (interrupt gate descriptors, na termino- 
logia Intel), cada um dos quais sendo uma estrutura de 8 bytes com vários campos. 

Existem vários modos de resposta às interrupções; no modo utilizado pelo MINIX 3, 
os campos de maior interesse para nós, em cada um dos descritores de interrupção, apontam 
para o segmento de memória onde reside o código executável da rotina de serviço e o endere- 
ço inicial da rotina dentro dele. A CPU executa o código apontado pelo descritor selecionado. 
O resultado é exatamente igual à da execução de uma instrução 


int <nnn> 


em linguagem assembly. A única diferença é que, no caso de uma interrupção de hardware, 
o número <nnn> originado por um registrador no chip controlador de interrupção e não por 
uma instrução na memória do programa. 

O mecanismo de troca de tarefas de um processador Intel de 32 bits que entra em ação 
em resposta a uma interrupção é complexo, e alterar o contador de programa para executar 
outra função é apenas uma parte dele. Se a CPU recebe uma interrupção enquanto está exe- 
cutando um processo ela configura uma nova pilha para uso durante o serviço de interrupção. 
A localização dessa pilha é determinada por uma entrada em um segmento de estado de 
tarefa (Task State Segment — TSS). Existe apenas uma estrutura dessas para o sistema in- 
teiro, inicializada por cstart ao chamar prot init e modificada à medida que cada processo 
é iniciado. O efeito é que a nova pilha criada por uma interrupção sempre começa no fim da 
estrutura stackframe _s, dentro da entrada da tabela de processos do processo interrompido. 
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A CPU coloca automaticamente vários registradores importantes nessa nova pilha, incluindo 
aqueles necessários para restabelecer a própria pilha do processo interrompido e restaurar 
seu contador de programa. Quando o código da rotina de tratamento de interrupção começa a 
ser executado, ele utiliza essa área da tabela de processos como sua pilha e grande parte das 
informações necessárias para retornar ao processo interrompido já estão ali armazenadas. A 
rotina de tratamento de interrupção armazena nesta pilha o conteúdo de outros registradores 
da CPU e depois troca para uma outra pilha fornecida pelo núcleo, enquanto faz o que for 
necessário para atender a interrupção. 

O término de uma rotina de serviço de interrupção é feito pela troca da pilha do núcleo 
para a estrutura de pilha na tabela de processos (mas não necessariamente a mesma que 
foi criada pela última interrupção), retirando explicitamente os valores dos registradores ali 
armazenados e executando uma instrução iretd (retorno de interrupção). A instrução iretd res- 
tabelece o estado existente antes de uma interrupção, restaurando os registradores que foram 
colocados pelo hardware e trocando para a pilha que estava em uso antes da interrupção ter 
sido gerado. Assim, uma interrupção pára um processo e o término do serviço de interrupção 
reinicia um processo, possivelmente diferente daquele que foi parado mais recentemente. Ao 
contrário dos mecanismos de interrupção mais simples, que são o assunto comum dos textos 
sobre programação em linguagem assembly, quando um processo de usuário é interrompido 
nada é armazenado na pilha de trabalho do processo interrompido. Além disso, como após 
uma interrupção, cada pilha é criada em um local desconhecido (determinado pelo TSS), o 
controle de vários processos é simplificado. Para iniciar um processo diferente, basta apontar 
o ponteiro de pilha para a estrutura de pilha de desse processo, retirar os registradores que 
foram colocados explicitamente e executar uma instrução iretd. 

A CPU desabilita todas as interrupções ao receber uma interrupção. Isso garante que 
não ocorra nada que possa fazer a estrutura de pilha dentro de uma entrada da tabela de pro- 
cessos estourar seus limites (overflow). Isso é automático, mas também existem instruções 
em nível de linguagem assembly para desabilitar e habilitar interrupções. As interrupções per- 
manecem desabilitadas enquanto a pilha do núcleo (localizada fora da tabela de processos) 
está sendo usada. Existe um mecanismo para permitir a execução de uma rotina de tratamento 
de exceção (uma resposta a um erro detectado pela CPU) quando a pilha do núcleo está 
sendo usada. Uma exceção é semelhante a uma interrupção, só que as exceções não podem 
ser desativadas. Assim, para as exceções deve haver uma maneira de tratar com o que são, 
basicamente, interrupções aninhadas. Nesse caso, não é criada uma nova pilha. Em vez disso, 
a CPU coloca os registradores essenciais necessários para a retomada do código interrompido 
na pilha existente. Entretanto, não devem ocorrer exceções enquanto o núcleo estiver sendo 
executado, caso contrário, essa situação resulta no que se denomina de pânico no núcleo 
(kernel panic). 

Quando ocorre uma instrução iretd dentro código do núcleo o mecanismo de retorno 
é mais simples do que aquele utilizado quando um processo de usuário é interrompido. O 
processador pode determinar como vai manipular a instrução iretd, examinando o seletor de 
segmento de código que é extraído da pilha como parte da ação de iretd. 

Os níveis de privilégio mencionados anteriormente controlam as diferentes respostas 
para as interrupções recebidas enquanto um processo está em execução e enquanto o código 
do núcleo (incluindo as rotinas de serviço de interrupção) está executando. O mecanismo 
mais simples é usado quando o nível de privilégio do código interrompido é igual ao nível de 
privilégio do código a ser executado em resposta à interrupção. O caso normal, entretanto, é o 
código interrompido ter menos privilégio do que o código do serviço de interrupção e, nesse 
caso, é empregado o mecanismo mais elaborado, usando o TSS e uma nova pilha. O nível de 
privilégio de um segmento de código é registrado no seletor de segmento de código e, como 
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esse é um dos itens empilhados durante uma interrupção, ele pode ser examinado no retorno 
da interrupção para determinar o que a instrução iretd deve fazer. 

Outro comportamento é implementado pelo hardware quando uma nova pilha é criada 
para ser utilizada durante o atendimento de uma interrupção. O hardware faz uma verificação 
para garantir que a nova pilha seja grande o suficiente, pelo menos para a quantidade mínima 
de informação que deve ser colocada nela. Isso evita que o código de maior privilégio do 
núcleo seja danificado acidentalmente (ou maldosamente) por um processo de usuário que 
esteja fazendo uma chamada de sistema com uma pilha inadequada. Esses mecanismos são 
incorporados ao processador especificamente para uso na implementação de sistemas opera- 
cionais que suportam vários processos. 

Esse comportamento pode ser confuso, caso você não esteja familiarizado com o fun- 
cionamento interno das CPUs Intel de 32 bits. Normalmente, tentamos não descrever tais de- 
talhes, mas entender o que acontece quando ocorre uma interrupção e quando uma instrução 
iretd é executada é fundamental para compreender como o núcleo controla as transições para 
o estado executando da Figura 2-2. O fato de o hardware tratar de grande parte do trabalho 
torna a vida do programador muito mais fácil e, presumivelmente, torna o sistema resultante 
mais eficiente. Contudo, toda essa ajuda do hardware dificulta entender exatamente o que está 
acontecendo apenas lendo o software. 

Tendo descrito o mecanismo de interrupção, voltaremos ao arquivo mpx386.s e examina- 
remos a minúscula parte do núcleo do MINIX 3 que realmente vê as interrupções de hardware. 
Existe um ponto de entrada para cada interrupção. O código-fonte em cada ponto de entrada, 
_hwint00 a _hwint07 (linhas 6531 a 6560), parecem com a chamada para hwint master (linha 
6515) e os pontos de entrada hwintO8 a hwint]5 (linhas 6583 a 6612) são similares à cha- 
mada para hwint slave (linha 6566). Cada ponto de entrada passa um parâmetro na chamada 
indicando qual dispositivo precisa de serviço. Na verdade, elas não são chamadas, mas ma- 
cros, e são geradas oito cópias separadas do código estabelecido pela definição de macro de 
hwint master, apenas com o parâmetro irq diferente. Analogamente, são criadas oito cópias 
da macro hwint slave. Isso pode parecer extravagante, mas o código gerado é muito com- 
pacto. O código-objeto de cada macro expandido ocupa menos de 40 bytes. No atendimento 
a uma interrupção, a velocidade é importante e isso elimina a sobrecarga de executar código 
para carregar um parâmetro, chamar uma sub-rotina e recuperar o parâmetro. 

Continuaremos a discussão sobre hAwint master como se na verdade fosse uma única 
função e não uma macro que é expandida em oito pontos diferentes. Lembre-se de que, antes 
que hAwint master comece a executar, a CPU criou, dentro da entrada na tabela de processos 
do processo interrompido, uma nova pilha na estrutura stackframe s. Vários registradores 
importantes já foram salvos lá e todas as interrupções estão desabilitadas. A primeira ação de 
hwint master é chamar save (linha 6516). Essa sub-rotina armazena na pilha todos os outros 
registradores necessários para reiniciar o processo interrompido. Para aumentar a velocidade, 
save poderia ter sido escrita de forma inline, como parte da macro, mas isso teria mais do que 
duplicado o tamanho da macro e, além disso, save é necessária em chamadas de outras fun- 
ções. Conforme veremos, save faz alguns truques com a pilha. No retorno para hwint master, 
está em uso a pilha do núcleo e não a estrutura de pilha da tabela de processos. 

Agora duas tabelas declaradas em glo.h são usadas. Irg handlers contém as infor- 
mações de gancho (hook) o que inclui os endereços das rotinas de tratamento. O termo gan- 
cho é uma analogia a que se pode pendurar qualquer coisa (informações nesse caso) neles. 
O número da interrupção que está sendo atendida é convertido em um endereço dentro de 
“irg handlers. Então, esse endereço é colocado na pilha como argumento de intr handle e 
“intr. handle é chamada. Veremos o código de intr handle posteriormente. Por enquanto, 
diremos que ela não apenas chama a rotina de serviço para a interrupção que foi solicitada, 
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como também configura ou reconfigura um flag no array _irq_actids, para indicar se a ten- 
tativa de atender a interrupção foi bem-sucedida, e dá às outras entradas nessa fila uma outra 
chance de executarem e serem removidas da lista. Dependendo do que foi exigido exatamente 
da rotina de tratamento, a IRQ pode ou não estar disponível para receber outra interrupção no 
retorno da chamada de intr handle. Isso é determinado pela verificação da entrada corres- 
pondente em irg actids. 

Um valor diferente de zero em irg actids mostra que o serviço de interrupção dessa 
IRQ não está terminado. Se assim for, o controlador de interrupção será programado para im- 
pedir que ele responda à outra interrupção da mesma linha de IRQ (linhas 6722 a 6724). Essa 
operação mascara a capacidade do chip controlador de responder a uma entrada em particular; 
a capacidade da CPU de responder a todas as interrupções é impedida internamente, quando 
ela recebe pela primeira vez o sinal de interrupção e ainda não foi restaurada nesse ponto. 

Algumas palavras sobre o código em linguagem assembly utilizado pode ser útil para os 
leitores não familiarizados com programas assembly. A instrução 


jz Of 


na linha 6521, não especifica um número de bytes a serem pulados. O valor Of não é um nú- 
mero hexadecimal nem um rótulo normal. Os nomes de rótulo normais não podem começar 
com caracteres numéricos. Essa é a maneira como o montador do MINIX 3 especifica um ró- 
tulo local; o valor Of significa um salto para frente (forward), para o próximo rótulo numé- 
rico 0, na linha 6525. O byte escrito na linha 6526 permite que o controlador de interrupção 
retome a operação normal, provavelmente com a linha da interrupção corrente desabilitada. 

Um ponto interessante, e possivelmente confuso, é que o rótulo O:, na linha 6525, ocor- 
re em outra parte do mesmo arquivo, na linha 6576, em hwint slave. A situação é ainda mais 
complicada do que parece à primeira vista, pois esses rótulos estão dentro de macros e as 
macros são expandidas antes que o montador veja esse código. Assim, existem na verdade 16 
rótulos 0: no código visto pelo montador. A possível proliferação de rótulos declarados dentro 
de macros é o motivo pelo qual a linguagem assembly fornece rótulos locais; ao resolver um 
rótulo local, o montador utiliza o mais próximo que combine na direção especificada e as 
ocorrências adicionais desse rótulo local são ignoradas. 

“Intr handle é dependente do hardware e os detalhes de seu código serão discutidos 
quando chegarmos ao arquivo i8259.c. Entretanto, agora são necessárias algumas palavras 
sobre seu funcionamento. Intr handle percorre uma lista encadeada de estruturas que con- 
têm, dentre outras coisas, endereços de funções a serem chamadas para tratar de uma inter- 
rupção de um dispositivo e os números de processo dos drivers de dispositivo. Essa é uma lis- 
ta encadeada porque uma única linha de IRQ pode ser compartilhada com vários dispositivos. 
A rotina de tratamento de cada dispositivo deve testar se seu dispositivo realmente precisa do 
serviço. É claro que essa etapa não é necessária para uma IRQ como a interrupção de relógio 
(IRQ 0) que é embutida no chip que gera a base de tempo, sem nenhuma possibilidade de 
qualquer outro dispositivo disparar essa IRQ. 

O código da rotina de tratamento deve ser escrito de modo que ela possa retornar rapida- 
mente. Se não houver nenhum trabalho a ser feito, ou o serviço de interrupção for concluído 
imediatamente, a rotina de tratamento retornará TRUE. Uma rotina de tratamento pode exe- 
cutar uma operação, como a leitura de dados de um dispositivo de entrada e a transferência 
dos dados para um buffer, onde eles podem ser acessados quando o driver correspondente ti- 
ver sua próxima chance de executar. A rotina de tratamento pode então enviar uma mensagem 
para seu driver de dispositivo, a qual, por sua vez, faz com que o driver de dispositivo tenha 
sua execução escalonada como um processo normal. Se o trabalho não estiver terminado, a 
rotina de tratamento retornará FALSE. Um dos elementos do array irg act ids é um mapa 
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de bits que registra os resultados de todas as rotinas de tratamento da lista de tal maneira que 
o resultado seja zero se e somente se cada uma das rotinas de tratamento retornou TRUE. Se 
isso não acontecer, o código nas linhas 6522 a 6524 desabilitará a IRQ antes que o controla- 
dor de interrupção como um todo seja habilitado na linha 6536. 

Esse mecanismo garante que nenhuma das rotinas de tratamento no encadeamento as- 
sociado a uma IRQ seja ativada até que todos os drivers de dispositivo ao qual elas pertencem 
tenham terminado seu trabalho. Obviamente, precisa haver outra maneira de reativar uma 
IRQ. Isso é fornecido em uma função enable irqg, que veremos posteriormente. Basta dizer 
que cada driver de dispositivo deve garantir que enable irq seja chamada quando seu traba- 
lho estiver terminado. Também é óbvio que enable irq deve primeiro reativar seu próprio bit 
no elemento de irg act ids correspondente à IRQ do driver e, então, deve testar se todos os 
bits foram reativados. Só então a IRQ pode ser reativada no chip controlador de interrupção. 

O que acabamos de descrever se aplica em sua forma mais simples apenas ao driver 
de relógio, pois o relógio é o único dispositivo orientado a interrupção que é compilado no 
binário do núcleo. O endereço de uma rotina de tratamento de interrupção em outro processo 
não tem significado algum no núcleo e a função enable irg no núcleo não pode ser chamada 
por um outro processo. Para os drivers de dispositivo em espaço de usuário, isto é, todos os 
drivers de dispositivo que respondem às interrupções iniciadas pelo hardware, exceto o driver 
de relógio, possuem um endereço de uma rotina de tratamento comum, a generic handler, 
armazenado na lista encadeada de ganchos. O código-fonte dessa função está nos arquivos de 
tarefa de sistema, mas como a tarefa de sistema é compilada junto com o núcleo, e como esse 
código é executado em resposta a uma interrupção, ele não pode ser considerado realmente 
como parte da tarefa de sistema. A outra informação em cada elemento da lista de ganchos 
inclui o número de processo do driver de dispositivo associado. Quando generic handler é 
chamada, ela envia uma mensagem para o driver de dispositivo correto, o que acarreta a exe- 
cução das funções da rotina de tratamento específicas ao driver. A tarefa de sistema também 
trata a outra ponta da cadeia de eventos descrita anteriormente. Quando um driver de dispo- 
sitivo em espaço de usuário termina seu trabalho, ele faz uma chamada de núcleo sys irqctl, 
a qual faz a tarefa de sistema chamar enable irg em nome desse driver, para preparar a 
próxima interrupção. 

Voltando nossa atenção para Awint master, note que ela termina com uma instrução ret 
(linha 6527). Não é óbvio que algo complicado acontece aqui. Se um processo tiver sido in- 
terrompido, a pilha em uso nesse ponto será a pilha do núcleo e não a que está dentro de uma 
entrada na tabela de processos, configurada pelo hardware antes que Awint master fosse ini- 
ciada. Nesse caso, a manipulação da pilha por save deixará o endereço de restart na pilha do 
núcleo. Isso resultará em uma tarefa, driver, servidor ou processo de usuário executando mais 
uma vez. Pode ser que não seja (e, na verdade, muito provavelmente não é) o mesmo processo 
que estava executando quando a interrupção ocorreu. Isso depende de o processamento da 
mensagem criado pela rotina do serviço de interrupção específica do dispositivo ter causado 
ou não uma alteração nas filas de escalonamento de processo. No caso de uma interrupção de 
hardware, isso quase sempre acontecerá. Normalmente, as rotinas de tratamento de interrup- 
ção resultam em mensagens para drivers de dispositivo e os drivers de dispositivo geralmente 
são postos em filas de prioridade mais alta do que os processos de usuário. Esse é, então, o 
centro do mecanismo que dá a ilusão de múltiplos processos executando simultaneamente. 

Para sermos completos, vamos mencionar que, se pudesse ocorrer uma interrupção en- 
quanto o código do núcleo estivesse em execução, a pilha do núcleo já estaria em uso e save 
deixaria o endereço de restart] nessa pilha. Nesse caso, o que o núcleo estivesse fazendo 
anteriormente continuaria após a instrução ret no final de Awint master. Esta é uma descrição 
do tratamento de interrupções aninhadas e elas não podem ocorrer no MINIX 3 — as interrup- 
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ções não são ativadas enquanto o código do núcleo está em execução. Entretanto, conforme 
mencionado anteriormente, o mecanismo é necessário para tratar das exceções. Quando to- 
das as rotinas do núcleo envolvidas na resposta a uma exceção tiverem terminado, restart 
finalmente será executada. Em resposta a uma exceção, enquanto o código do núcleo está 
executando, quase certamente será verdade que será escalonado um processo diferente do que 
foi interrompido. A resposta à ocorrência de uma exceção dentro do núcleo é uma situação de 
pânico que provocará uma tentativa de desligamento do sistema com o menor dano possível. 

Hwint slave (linha 6566) é semelhante a Awint master, exceto que deve reativar os 
controladores mestre e escravo, pois ambos são desativados pela recepção de uma interrupção 
por parte do escravo. 

Agora, vamos ver save (linha 6622), que já mencionamos. Seu nome descreve apenas 
uma de suas funções, que é salvar o contexto do processo interrompido na pilha fornecida 
pela CPU a qual é uma estrutura de pilha dentro da tabela de processos. Save utiliza a variável 
_k_reenter para contar e determinar o nível de aninhamento das interrupções. Se um processo 
estiver em execução no momento em que a interrupção corrente ocorrer, a instrução 


mov esp, k stktop 


na linha 6635, trocaria para a pilha do núcleo e a instrução seguinte colocaria nela o endereço 
de restart. Se ocorresse uma interrupção enquanto a pilha do núcleo já estivesse em uso, o 
endereço de restart] é que seria colocado (linha 6642). Naturalmente, não é permitida uma 
interrupção aqui, mas o mecanismo está presente para tratar de exceções. Em qualquer caso, 
com uma pilha possivelmente diferente daquela que estava em uso no momento da chamada 
e com o endereço de retorno armazenado nos registradores que acabaram de ser empilhadas, 
uma instrução return normal não é adequada para retornar à função que fez a chamada. As 
instruções 


imp — RETADR-P STACKBASE(eax) 


que estão nos dois pontos de término possíveis de save, na linha 6638 e na linha 6643, utili- 
zam o endereço de retorno que foi colocado na pilha quando save foi chamada. 

A reentrância no núcleo causava muitos problemas e eliminá-la resultou na simplifica- 
ção do código em vários lugares. No MINIX 3, a variável k reenter ainda tem um propósito 
— embora interrupções normais não possam ocorrer enquanto o código do núcleo está em 
execução, exceções ainda são possíveis. Por enquanto, o que se deve lembrar é que o salto 
na linha 6634 nunca ocorrerá na operação normal. Entretanto, ele é necessário para tratar de 
exceções. 

Além disso, devemos admitir que a eliminação da reentrância é um caso onde a pro- 
gramação se antecipou à documentação no desenvolvimento do MINIX 3. De certa forma, 
documentar é mais difícil do que programar — o compilador ou o programa eventualmente 
revelarão erros em um programa. Não existe um mecanismo assim para corrigir comentários 
no código-fonte. Há um comentário bastante longo no início de mpx386.s que, infelizmente, 
está incorreto. A parte do comentário nas linhas 6310 a 6315 deveria dizer que a reentrada no 
núcleo só pode ocorrer quando uma exceção for detectada. 

A função seguinte em mpx366.s é s call, que começa na linha 6649. Antes de exami- 
nar seus detalhes internos, veja como ela termina. Ela não acaba com uma instrução ret ou 
jmp. Na verdade, a execução continua em _restart (linha 6681). .S call é parte da chamada 
de sistema no mecanismo de tratamento de interrupção. O controle chega em s call após 
uma interrupção de software; isto é, após a execução de uma instrução int <nnn>. As interrup- 
ções de software são tratadas como as interrupções de hardware, exceto, é claro, que o índice 
para a tabela de descritores de interrupção é codificado na parte nnn de uma instrução int 
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<nnn>, em vez de ser fornecido por um chip controlador de interrupção. Assim, quando se en- 
traem s call, a CPU já trocou para uma pilha dentro da tabela de processos (fornecida pelo 
TSS) e vários registradores já foram colocados nessa pilha. Indo para restart, a chamada de 
“Ss call termina, em última análise, com uma instrução iretd e, exatamente como acontece 
com uma interrupção de hardware, essa instrução iniciará o processo que for apontado por 
proc. ptr nesse ponto. A Figura 2-40 compara o tratamento de uma interrupção de hardware e 
uma chamada de sistema usando o mecanismo de interrupção de software. 


Dispositivo: 
Envia sinal elétrico para o controlador 
de interrupção. 


Controlador: Função que faz uma chamada de sistema 
1. Interrompe a CPU. 1. Coloca o ponteiro de mensagem e o destino da 
2. Envia identificação do dispositivo que gerou mensagem nos registradores da CPU. 


a interrupção. 2. Executa a instrução de interrupção de software. 


Núcleo: Núcleo: 
1. Salva os registradores. 1. Salva os registradores. 
2. Envia mensagem de notificação para o driver 2. Envia e/ou recebe mensagem. 
3. Reinicia um processo (provavelmente o driver) 3. Reinicia um processo (não necessariamente 
o que fez a chamada). 


(a) (b) 


Figura 2-40 (a) Como uma interrupção de hardware é processada. (b) Como é feita uma 
chamada de sistema. 


Vamos ver agora alguns detalhes de _s_call. O rótulo alternativo, _p_s_call, é um ves- 
tígio da versão de 16 bits do MINIX 3, que tem rotinas separadas para operação no modo 
protegido e no modo real. Na versão de 32 bits, todas as chamadas para um dos dois rótulos 
terminam aqui. Um programador que faz uma chamada de sistema do MINIX 3 escreve 
uma chamada de função em C parecida com qualquer uma outra, seja para uma função 
definida de forma local ou para uma função da biblioteca C. O código de biblioteca que su- 
porta uma chamada de sistema configura uma mensagem, carrega o endereço da mensagem 
e a id do processo do destino nos registradores da CPU e, então, aciona uma instrução int 
SYS386_VECTOR. Conforme descrito anteriormente, o resultado é que o controle passa 
para o início de _s_call e vários registradores já foram armazenados na pilha dentro da ta- 
bela de processos. Além disso, como acontece com uma interrupção de hardware, todas as 
interrupções são desativadas. 

A primeira parte do código de _s_call é semelhante a uma expansão em linha de save e 
salva os registradores adicionais que devem ser preservados. Exatamente como acontece em 
save, uma instrução 


mov esp, k_stktop 


troca, então, para a pilha do núcleo. (A semelhança de uma interrupção de software com 
uma interrupção de hardware estende-se a ambos, desativando todas as interrupções.) Depois 
disso, vem uma chamada para _sys_call (linha 6672), que discutiremos na próxima seção. 
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Por enquanto, diremos apenas que ela faz uma mensagem ser enviada e que esta, por sua vez, 
faz o escalonador funcionar. Assim, quando sys call retorna, é provável que proc ptr esteja 
apontando para um processo diferente daquele que iniciou a chamada de sistema. Então, a 
execução vai para restart. 

Vimos que _restart (linha 6681) é alcançada de várias maneiras: 


1. Por uma chamada de main, quando o sistema inicia. 


2. Por um desvio em Awint master ou hwint slave, após uma interrupção de hardwa- 
re. 


3. Por meio de s call, após uma chamada de sistema. 


A Figura 2-41 é um resumo simplificado de como o controle alterna entre os processos 
e o núcleo por meio de restart. 


v Inicialização” ; 
~~a frio- 


Processo 
ou tarefa 


restart() 


Espaço de 
usuário 


syscall() 


interrupção externa interrupção de software 
(de hardware ou relógio) (chamada de sistema) ı 


Figura 2-41 Restart é o ponto comum atingido após a inicialização do sistema, interrupções 
ou chamadas de sistema. Um processo (que pode ser, e freqüentemente é, diferente do último 
a ser interrompido) é executado em seguida. Neste diagrama não aparecem as interrupções 
que ocorrem enquanto o próprio núcleo está em execução. 


Em cada caso, as interrupções são desativadas quando _restart é alcançada. Na linha 
6690, o próximo processo a ser executado foi escolhido e, com as interrupções desativadas, 
ele não pode ser alterado. A tabela de processos foi cuidadosamente construída de modo a 
começar com uma estrutura de pilha, e a instrução nessa linha, 


mov esp, (_proc_ptr) 
aponta para o registrador de ponteiro de pilha da CPU na estrutura de pilha. A instrução 
lidt P_LDT_SEL(esp) 


carrega, então, o registrador da tabela descritora local do processador, a partir da estrutura de 
pilha. Isso prepara o processador para usar os segmentos de memória pertencentes ao próxi- 
mo processo a ser executado. A instrução seguinte configura o endereço da entrada da tabela 
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de processos do próximo processo como aquele onde a pilha da próxima interrupção será 
configurada, e a instrução seguinte armazena esse endereço no TSS. 

A primeira parte de  restart não seria necessária se ocorresse uma interrupção quando 
o código do núcleo (incluindo o código do serviço de interrupção) estivesse sendo executa- 
do, pois a pilha do núcleo estaria em uso e o término do serviço de interrupção permitiria 
o código do núcleo continuar. Mas, na verdade, o núcleo não é reentrante no MINIX 3 e 
interrupções normais não podem ocorrer dessa maneira. Entretanto, desativar as interrupções 
não impede a capacidade do processador de detectar exceções. O rótulo restart1 (linha 6694) 
marca o ponto onde a execução será retomada se ocorrer uma exceção durante a execução do 
código do núcleo (algo que esperamos que nunca aconteça). Neste ponto, k reenter é decre- 
mentada para registrar que um nível de interrupções possivelmente aninhadas foi descartado 
e as instruções restantes restauram o processador no estado em que estava quando o processo 
seguinte foi executado pela última vez. A penúltima instrução modifica o ponteiro da pilha 
para que o endereço de retorno colocado quando save foi chamada seja ignorado. Se a última 
interrupção ocorreu quando um processo estava em execução, a instrução final, iretd, com- 
pleta o retorno para a execução do processo que tinha permissão para executar em seguida, 
restaurando seus registradores restantes, incluindo seu segmento de pilha e seu ponteiro de 
pilha. Entretanto, se a instrução iretd for atingida por meio de restart], a pilha do núcleo em 
uso não é uma estrutura de pilha, mas sim a própria pilha do núcleo, e isso não é um retorno 
para um processo interrompido, mas a conclusão do tratamento de uma exceção ocorrida du- 
rante a execução do núcleo. A CPU detecta isso quando o descritor de segmento de código é 
retirado da pilha, durante a execução da instrução iretd, e a ação completa de iretd, neste caso, 
é manter a pilha do núcleo em uso. 

Agora é hora de dizer algo mais sobre as exceções. Uma exceção é causada por vá- 
rias condições de erro internas da CPU. As exceções nem sempre são ruins. Elas podem ser 
utilizadas para estimular o sistema operacional a fornecer um serviço, como providenciar 
mais memória para um processo ou fazer swapping de uma página de memória, embora tais 
serviços não sejam implementados no MINIX 3. Elas também podem ser causadas por erros 
de programação. Dentro do núcleo, uma exceção é muito séria e causa uma situação de pâ- 
nico. Quando uma exceção ocorrer em um programa de usuário, talvez esse programa tenha 
de ser terminado, mas o sistema operacional deve ser capaz de continuar. As exceções são 
tratadas pelo mesmo mecanismo das interrupções, usando descritores na tabela de descritores 
de interrupção. Essas entradas na tabela apontam para os 16 pontos de entradas de rotina 
de tratamento de exceção, começando com divide error e terminando com copr error, 
encontrados próximos ao final de mpx386.s, nas linhas 6707 a 6769. Todos eles desviam para 
exception (linha 6774) ou para errexception (linha 6785), dependendo de a condição colocar 
um código de erro na pilha ou não. Aqui, o tratamento no código assembly é semelhante ao 
que já vimos; registradores são colocados na pilha e a rotina C exception (note o sublinhado) 
é chamada para tratar do evento. As conseqgiiências das exceções variam. Umas são ignora- 
das, outras causam situações de pânico e algumas resultam no envio de sinais para processos. 
Examinaremos exception em uma seção posterior. 

Um outro ponto de entrada é tratado como uma interrupção: levelO call (linha 6714). 
Ele é usado quando o código deve ser executado com nível de privilégio 0, o nível mais alto. 
O ponto de entrada está aqui em mpx386.s, com os pontos de entrada de interrupção e ex- 
ceção, pois ele também é ativado pela execução de uma instrução int <nnn>. Assim como as 
rotinas de exceção, ele chama save e, portanto, o código para o qual desvia terminará com 
uma instrução ret que leva a restart. Sua utilização será descrita em uma seção posterior, 
quando encontrarmos algum código que precise de privilégios normalmente não disponíveis 
mesmo para o núcleo. 
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Finalmente, um espaço para armazenamento de dados é reservado no final do arquivo em 
linguagem assembly. Dois segmentos de dados diferentes são definidos aqui. A declaração 


.sect .rom 


na linha 6822, garante que esse espaço de armazenamento seja alocado bem no início do 
segmento de dados do núcleo e que ele seja o início de uma seção somente de leitura da 
memória. O compilador coloca um número mágico (um código, na verdade) aqui, para que 
boot possa verificar se o arquivo carregado é uma imagem válida do núcleo. Ao se compilar 
o sistema completo, várias constantes de string serão armazenadas depois disso. A outra área 
de armazenamento de dados definida na declaração 


sect .bss 


(linha 6825) reserva espaço na área de dados não inicializada do núcleo para sua própria 
pilha e, acima dessa área, é reservado um espaço para as variáveis usadas pelas rotinas de 
tratamento de exceção. Os servidores e os processos normais têm seu espaço de pilha defi- 
nido no momento da criação do arquivo executável e dependem do núcleo para configurar 
corretamente o descritor de segmento de pilha e o ponteiro de pilha, quando são executados. 
O núcleo precisa fazer isso sozinho. 


Comunicação entre processos no MINIX 3 


No MINIX 3, os processos se comunicam por meio de mensagens, usando o princípio do 
rendez-vous. Quando um processo executa uma operação send, a camada inferior do núcleo 
verifica se o destino está esperando uma mensagem do remetente (ou do remetente ANY). 
Se estiver, a mensagem será copiada do buffer do remetente para o buffer do destinatário e 
os dois processos serão marcados como executáveis. Se o destino não estiver esperando uma 
mensagem do remetente, este será marcado como bloqueado e colocado em uma fila de pro- 
cessos em espera para enviar ao destinatário. 

Quando um processo executa uma operação receive, o núcleo verifica se algum pro- 
cesso está enfileirado, tentando enviar para ele. Se assim for, a mensagem será copiada do 
remetente bloqueado para o destinatário e ambos serão marcados como executáveis. Se ne- 
nhum processo estiver enfileirado tentando enviar para ele, o destinatário será bloqueado até 
a chegada de uma mensagem. 

No MINIX 3, com os componentes do sistema operacional sendo executados como 
processos totalmente separados, às vezes o método do rendez-vous não é bom o suficiente. 
A primitiva notify é fornecida precisamente para essas ocasiões. Uma instrução notify envia 
uma mensagem simples. O remetente não é bloqueado se o destino não está esperando uma 
mensagem. Contudo, a notificação não é perdida. Na próxima vez que o destino executar uma 
operação receive, as notificações pendentes serão entregues antes das mensagens normais. As 
notificações podem ser usadas em situações onde o uso de mensagens normais poderia causar 
impasses. Anteriormente, mencionamos que deve ser evitada a situação onde o processo A é 
bloqueado enviando uma mensagem para o processo B e o processo B é bloqueado enviando 
uma mensagem para o processo A. Mas se uma das mensagens for uma notificação não-blo- 
queante, não haverá problema algum. 

Na maioria dos casos, uma notificação informa o destinatário sobre sua origem e prati- 
camente mais nada. Às vezes, basta isso, mas existem dois casos especiais onde uma notifi- 
cação transmite informações adicionais. Em qualquer um deles, o processo de destino pode 
enviar uma mensagem para a fonte da notificação solicitando mais informações. 
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O código de alto nível da comunicação entre processos encontra-se em proc.c. A tarefa 
do núcleo é transformar uma interrupção de hardware ou uma interrupção de software em 
uma mensagem. A primeira é gerada pelo hardware e a última é a maneira como um pedido 
de serviços de sistema, isto é, uma chamada de sistema, é comunicada ao núcleo. Esses casos 
são semelhantes o suficiente para que possam ser manipulados por uma única função, mas foi 
mais eficiente criar funções especializadas. 

Um comentário e duas definições de macros, próximas ao início desse arquivo, são 
dignos de nota. Para manipular listas, são usados extensivamente ponteiros para ponteiros, e 
um comentário nas linhas 7420 a 7436 explica suas vantagens e seu uso. Duas macros úteis 
são definidas. BuildMess (linhas 7458 a 7471), embora seu nome implique em algo mais 
genérico, ela é usada apenas para construir as mensagens usadas por notify. A única chamada 
de função é para get uptime, que lê uma variável mantida pela tarefa de relógio para que a 
notificação possa incluir uma indicação de tempo (timestamp). As chamadas aparentes para 
uma função denominada priv são expansões de outra macro, definida em priv.h, 


Hdefine priv(rp) ((rp)->p. priv) 


A outra macro, CopyMess, é uma interface amigável para o programador, para a rotina 
em linguagem assembly cp mess em klib386.s. 

Mais deve ser dito a respeito de BuildMess. A macro priv é usada para dois casos es- 
peciais. Se a origem de uma notificação for HARDWARE, ela transportará uma cópia do 
mapa de bits de interrupções pendentes do processo de destino. Se a origem for SYSTEM, os 
dados transportados correspondem ao mapa de bits de sinais pendentes. Como esses mapas 
de bits estão disponíveis na entrada de tabela de priv do processo de destino, eles podem ser 
acessados a qualquer momento. As notificações podem ser entregues posteriormente, caso 
o processo de destino não esteja bloqueado esperando por elas no momento em que forem 
enviadas. Para mensagens normais, isso exigiria algum tipo de buffer no qual uma mensagem 
não enviada pudesse ser armazenada. Para armazenar uma notificação basta um mapa de bits 
no qual cada bit corresponda a um processo que pode enviar uma notificação. Quando uma 
notificação não pode ser enviada, o bit correspondente ao remetente é ativado no mapa de bits 
do destinatário. Quando uma operação receive é executada, o mapa de bits é verificado e se 
for encontrado um bit ativado, a mensagem será novamente gerada. O bit informa a origem 
da mensagem e se a origem for HARDWARE ou SYSTEM, o conteúdo adicional será acres- 
centado. O único outro item necessário é a indicação de tempo, que é adicionada quando a 
mensagem é reenviada. Para os propósitos para os quais são usadas, as indicações de tempo 
não precisam aparecer quando uma notificação foi tentada pela primeira vez, o tempo da 
entrega é suficiente. 

A primeira função em proc.c é sys. call (linha 7480). Ela converte uma interrupção de 
software (a instrução int SYS386 VECTOR por meio da qual uma chamada de sistema é ini- 
ciada) em uma mensagem. Existe uma ampla variedade de origens e destinos possíveis e a 
chamada pode exigir o envio ou o recebimento (ou ambos) de uma mensagem. Vários testes 
devem ser feitos. Nas linhas 7480 e 7481, o código da função (SEND, RECEIVE etc.) e os flags 
são extraídos do primeiro argumento da chamada. O primeiro teste serve para ver se o processo 
que fez a chamada pode mesmo fazê-la. Iskerneln, usada na linha 7501, é uma macro definida 
em proc.h (linha 5584). O teste seguinte serve para ver se a origem ou o destino especificado 
é um processo válido. Então, é feita uma verificação para saber se o ponteiro da mensagem 
aponta para uma área de memória válida. Os privilégios do MINIX 3 definem para quais ou- 
tros processos qualquer processo dado pode enviar, e isso é testado a seguir (linhas 7537 a 
7541). Finalmente, é feito um teste para verificar se o processo de destino está em execução e 
não iniciou um procedimento de parada, isto é, shutdown (linhas 7543 a 7547). Após todos os 
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testes terem sido passados, uma das funções mini send, mini receive ou mini notify é chama- 
da para fazer o trabalho real. Se a função era ECHO, a macro CopyMess é usada, com origem e 
destino idênticos. ECHO serve apenas para teste, conforme mencionado anteriormente. 

As condições de erro testadas em sys. call são improváveis, mas os testes são realizados 
facilmente, pois, em última análise, eles são compilados no código para fazer comparações 
entre inteiros. Nesse nível mais básico do sistema operacional, é aconselhável testar até o erro 
mais improvável. Esse código provavelmente será executado muitas vezes a cada segundo 
enquanto o computador que executa o sistema estiver ativo. 

As funções mini send, mini rec e mini notify são o centro do mecanismo normal de 
passagem de mensagens do MINIX 3 e merecem um estudo cuidadoso. 

Mini send (linha 7591) tem três parâmetros: o processo que fez a chamada, o processo 
destino e um ponteiro para o buffer onde a mensagem está armazenada. Após todos os testes 
realizados por sys call, apenas mais um é necessário, que é detectar um impasse no envio. O 
teste nas linhas 7606 a 7610 verifica se o processo que fez a chamada e o destino não estão 
tentando um enviar para o outro. O teste principal em mini send está nas linhas 7615 e 7616. 
Aqui, é feita uma verificação para saber se o destino está bloqueado em uma operação recei- 
ve, conforme mostrado pelo bit RECEIVING no campo p rts flags de sua entrada na tabela 
de processos. Se ele estiver esperando, a próxima pergunta é: “Por quem ele está esperando?”. 
Se ele estiver esperando pelo remetente, ou por ANY, a macro CopyMess será usada para co- 
piar a mensagem e o destinatário será desbloqueado, reativando seu bit RECEIVING. Então, 
enqueue é chamada para dar ao destinatário uma oportunidade de executar (linha 7620). 

Se, por outro lado, o destinatário não estiver bloqueado, ou se estiver bloqueado es- 
perando uma mensagem de outro processo, o código das linhas 7623 a 7632 será executado 
para bloquear e retirar o remetente da fila. Todos os processos que estão querendo enviar para 
determinado destino são enfileirados em uma lista encadeada, com o campo p callerg do des- 
tino apontando para a entrada da tabela de processos do processo que está no início da fila. O 
exemplo da Figura 2-42(a) mostra o que acontece quando o processo 3 não é capaz de enviar 
para o processo 0. Se, subsegiientemente, o processo 4 também for incapaz de enviar para o 
processo 0, teremos a situação da Figura 2-42(b). 


p q link = 0 
p q link 


p q link = 0 


p caller q 


p caller q 


O- NORA 


(a) (b) 


Figura 2-42 Enfileiramento de processos tentando enviar para o processo 0. 


Mini_receive (linha 7642) é chamada por sys_call quando seu parâmetro function é RE- 
CEIVE ou BOTH. Conforme mencionamos anteriormente, as notificações têm prioridade mais 
alta do que as mensagens normais. Entretanto, uma notificação nunca será a resposta direta 
para uma instrução send; portanto, os mapas de bits só serão consultados para verificar se 
existem notificações pendentes quando o flag SENDREC_BUSY não estiver ativado. Se for 
encontrada uma notificação, ela será marcada como não mais pendente e enviada (linhas 7670 
a 7685). O envio utiliza as macros BuildMess e CopyMess definidas perto do início de proc.c. 
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Poderia se pensar que, como uma indicação de tempo faz parte de uma mensagem 
notify, ela transmitíria informações úteis; por exemplo, se o destinatário não fosse capaz de 
executar uma operação receive por algum tempo, a indicação de tempo informaria por quanto 
tempo ela não foi enviada. Mas a mensagem de notificação é gerada (e tem a indicação de 
tempo anexada) no momento em que é entregue e não quando foi enviada. Contudo, há um 
propósito por trás da construção das mensagens de notificação no momento da entrega. O 
código é desnecessário para salvar mensagens de notificação que não podem ser entregues 
imediatamente. Basta ativar um bit para lembrar que uma notificação deve ser gerada quando 
a entrega se tornar possível. Você não pode ter um armazenamento mais econômico do que 
esse: um único bit por notificação pendente. 

Também acontece que, normalmente, o tempo atual é tudo o que é necessário. Por 
exemplo, se uma notificação fosse usada para entregar uma mensagem SYN ALARM ao ge- 
renciador de processos sem que a indicação de tempo constasse nela, este teria que consultar 
o núcleo para obter a informação de tempo atual antes de acessar sua estrutura de fila. 

Note que apenas uma notificação é entregue por vez; mini send retorna na linha 7684, 
após a entrega de uma notificação. Mas o processo que fez a chamada não é bloqueado; portan- 
to, ele está livre para executar outra operação receive imediatamente após receber a notificação. 
Se não houver notificações, as filas do processo que fez a chamada são verificadas para verificar 
se está pendente uma mensagem de qualquer outro tipo (linhas 7690 a 7699). Se uma mensa- 
gem for encontrada, ela será entregue pela macro CopyMess e o remetente da mensagem será, 
então, desbloqueado pela chamada para enqueue na linha 7694. O processo que fez a chamada 
não é bloqueado, neste caso. Se nenhuma notificação, ou outra mensagem, estivesse disponível, 
o processo que fez a chamada seria bloqueado pela chamada para dequeue na linha 7708. 

Mini notify (linha 7719) é usada para efetuar uma notificação. Ela é semelhante à 
mini send e pode ser discutida rapidamente. Se o destinatário de uma mensagem estiver 
bloqueado e esperando para receber, a notificação será gerada e entregue por BuildMess. O 
flag RECEIVING do destinatário se torna desativado e então é recolocado em enqueue (linhas 
7738 a 7743). Se o destinatário não estiver esperando por mensagem, um bit será ativado 
em seu mapa s notify pending, que indica que uma notificação está pendente e identifica o 
remetente. O remetente continua então seu próprio trabalho e se for necessária outra notifica- 
ção para o mesmo destinatário antes de uma anterior ter sido recebida, o bit no mapa de bits 
do destinatário será sobrescrito — efetivamente, várias notificações do mesmo remetente são 
mescladas em uma única mensagem de notificação. Esse projeto elimina a necessidade de 
gerenciamento de buffer, enquanto provê passagem de mensagem assíncrona. 

Quando mini notify for executada devido a uma interrupção de software e, subseqiien- 
temente, uma chamada para sys call, as interrupções serão desativadas. Mas as tarefas de 
relógio ou de sistema, ou alguma outra tarefa que possa ser adicionada no MINIX 3 no fu- 
turo, talvez precise enviar uma notificação em um momento no qual as interrupções não 
estão desativadas. Lock notify (linha 7758) é uma entrada segura para mini notify. Ela veri- 
fica k reenter para ver se as interrupções já estão desativadas e, se estiverem, apenas chama 
mini notify imediatamente. Se as interrupções estiverem ativadas, elas serão desativadas por 
uma chamada para lock, mini notify será chamada e, então, as interrupções serão reativadas 
por uma chamada para unlock. 


Escalonamento no MINIX 3 

O MINIX 3 usa um algoritmo de escalonamento multinível. Os processos recebem priori- 
dades iniciais, relacionadas à estrutura mostrada na Figura 2-29, mas existem mais camadas 
e a prioridade de um processo pode mudar durante sua execução. As tarefas de relógio e de 
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sistema, na camada 1 da Figura 2-29, recebem a prioridade mais alta. Os drivers de dispo- 
sitivo da camada 2 recebem prioridade mais baixa, mas nem todos são iguais. Os processos 
de servidor na camada 3 recebem prioridades mais baixas do que os drivers. Os processos 
de usuário começam com prioridade menor do que qualquer um dos processos de sistema e 
inicialmente são todos iguais, mas o comando nice pode aumentar ou diminuir a prioridade 
de um processo de usuário. 

O escalonador mantém 16 filas de processos prontos para executar (aptos), embora nem 
todos eles possam ser usados em dado momento. A Figura 2-43 mostra as filas e os processos 
que estão em vigor no instante em que o núcleo termina a inicialização e começa a executar; 
isto é, na chamada para restart, na linha 7252, em main.c. O array rdy head tem uma en- 
trada para cada fila, com essa entrada apontando para o processo que está no início da fila. 
Analogamente, rdy tail é um array cujas entradas apontam para o último processo em cada 
fila. Esses dois arrays são definidos com a macro EXTERN em proc.h (linhas 5595 e 5596). 
O enfileiramento inicial de processos durante a inicialização do sistema é determinado pela 
tabela image em table.c (linhas 6095 a 6109). 
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Figura 2-43 O escalonador mantém 16 filas, uma por nível de prioridade. Aqui está mostra- 
do o enfileiramento inicial de processos quando o MINIX 3 é inicializado. 


O escalonamento em cada fila é round-robin. Se um processo em execução utiliza seu 
quantum, ele é movido para o final de sua fila e recebe um novo quantum. Entretanto, quando 
um processo bloqueado é despertado, se tiver sobrado uma parte de seu quantum quando foi 
bloqueado, ele é posto no início de sua fila. Isto é, ele não recebe um novo quantum completo; 
ele recebe apenas o que restava quando foi bloqueado. A existência do array rdy tail torna 
a adição de um processo no final de uma fila eficiente. Quando um processo em execução é 
bloqueado, ou quando um processo apto é eliminado por um sinal, o mesmo é removido das 
filas do escalonador. Somente os processos aptos a executar são enfileirados. 

Dadas as estruturas de fila que acabamos de descrever, o algoritmo de escalonamento é 
simples: encontrar a fila de prioridade mais alta que não esteja vazia e escolher o processo que 
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está no início dessa fila. O processo IDLE está sempre pronto e fica na fila de prioridade mais bai- 
xa. Se todas as filas de prioridade mais alta estiverem vazias, o processo IDLE será executado. 

Vimos várias referências a enqueue e dequeue na última seção. Agora, vamos exami- 
ná-las. Enqueue é chamada com um ponteiro para uma entrada na tabela de processos como 
argumento (linha 7787). Ela chama outra função, sched, com ponteiros para variáveis que 
determinam em qual fila o processo deve estar e se ele deve ser adicionado no início ou no 
final dessa fila. Agora, existem três possibilidades. Esses são exemplos clássicos de estrutu- 
ras de dados. Se a fila escolhida estiver vazia, tanto rdy head como rdy tail apontarão para 
o processo que está sendo adicionado e o campo de encadeamento, p nextready, receberá 
o valor de ponteiro especial que indica que nada vem a seguir, NIL PROC. Se o processo 
estiver sendo adicionado no início de uma fila, seu ponteiro p nextready receberá o valor 
corrente de rdy head e, então, rdy head apontará para o novo processo. Se o processo estiver 
sendo adicionado no final de uma fila, o ponteiro p nextready do ocupante atual do final da 
fila apontará para o novo processo, assim como rdy tail. Então, o ponteiro p nextready do 
processo que acabou de ficar pronto apontará para NIL PROC. Finalmente, pick proc será 
chamada para determinar qual processo será executado em seguida. 

Quando um processo deve sair da fila de aptos a executar, a função dequeue (linha 
7823) é chamada. Um processo deve estar em execução para ser bloqueado; portanto, o pro- 
cesso a ser removido provavelmente estará no início de sua fila. Entretanto, um sinal poderia 
ter sido enviado para um processo que não estava em execução. Então, a fila é percorrida para 
se localizar a “vítima”, com uma alta probabilidade de o processo ser encontrado no seu iní- 
cio. Quando ele é encontrado, todos os ponteiros são ajustados adequadamente, para retirá-lo 
do encadeamento. Se ele estava em execução, pick proc também deve ser chamada. 

Outro ponto de interesse é encontrado nessa função. Como as tarefas executadas no 
núcleo compartilham uma área de pilha definida pelo hardware comum, é uma boa idéia ve- 
rificar a integridade de suas áreas de pilha ocasionalmente. No início de degueue é feito um 
teste para ver se o processo que está sendo removido da fila executa em espaço de núcleo. Se 
executar, é feita uma verificação para saber se um padrão característico, escrito no final de sua 
área de pilha, não foi sobrescrito (linhas 7835 a 7838). 

Agora chegamos a sched, que escolhe a fila em que vai colocar um processo que se 
tornou pronto recentemente e se vai inseri-lo no início ou no final dessa fila. Na tabela de 
processos de cada processo está gravado seu quantum, o tempo que resta de seu quantum, sua 
prioridade e a prioridade máxima permitida. Nas linhas 7880 a 7885, é feita uma verificação 
para saber se o quantum inteiro foi usado. Se não foi, ele será reiniciado com o que tiver 
restado de sua última vez. Se o quantum foi todo utilizado, então é feita uma verificação para 
saber se o processo teve dois turnos seguidos, sem que nenhum outro processo tenha executa- 
do. Isso é considerado um sinal de um possível laço infinito (ou pelos menos excessivamente 
longo) e é atribuída uma penalidade de +1. Entretanto, se o quantum inteiro foi utilizado, mas 
outros processos tiveram uma chance de executar, o valor da penalidade se tornará -1. É claro 
que isso não ajudará caso dois ou mais processos estejam sendo executados juntos em um 
laço. O modo de detectar isso é um problema em aberto. 

Em seguida, é determinada a fila a ser usada. A fila O é a de prioridade mais alta; a fila 
15 é a de prioridade mais baixa. Alguém poderia dizer que isso deveria ser feito de outra 
forma, mas essa maneira está de acordo com os valores tradicional de nice utilizados pelo 
UNIX, onde um valor positivo significa um processo executando com prioridade mais baixa. 
Os processos do núcleo (as tarefas de relógio e de sistema) são imunes ao valor de nice, mas 
todos os outros processos podem ter suas prioridades reduzidas; ou seja, podem ser movidos 
para uma fila numericamente mais alta, adicionado-se uma penalidade positiva. Todos os pro- 
cessos começam com sua prioridade máxima; portanto, uma penalidade negativa não muda 
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nada, até que tenham sido atribuídas penalidades positivas. Também existe um limite inferior 
para a prioridade; os processos normais nunca podem ser colocados na mesma fila de IDLE. 

Agora, chegamos a pick proc (linha 7910). A principal tarefa dessa função é configurar 
next_ptr. Toda alteração nas filas que possa afetar a escolha do processo a ser executado em 
seguida exige que pick_proc seja novamente executada. Quando o processo corrente é blo- 
queado, pick_proc é chamada para determinar quem usará da CPU. Basicamente, pick_proc 
é o escalonador. 

Pick proc é simples. Cada fila é testada. Primeiro é testado TASK OQ e, se um pro- 
cesso dessa fila estiver pronto, pick proc configurará proc ptr e retornará imediatamente. 
Caso contrário, a próxima fila de prioridade mais baixa é testada, descendo até IDLE Q. O 
ponteiro bill ptr é alterado para cobrar o processo de usuário pelo tempo da CPU que está 
para receber (linha 77694). Isso garante que o último processo de usuário a ser executado seja 
cobrado pelo trabalho feito pelo sistema em seu nome. 

As funções restantes em proc.c são lock send, lock engueue e lock dequeue. Todas 
elas dão acesso às suas funções básicas usando lock e unlock, da mesma maneira como dis- 
cutimos para lock notif. 

Em resumo, o algoritmo de escalonamento mantém várias filas de prioridade. O primei- 
ro processo da fila de prioridade mais alta é sempre executado em seguida. A tarefa de relógio 
monitora o tempo usado por todos os processos. Se um processo de usuário utiliza todo seu 
quantum, ele é colocado no final de sua fila, obtendo-se assim um escalonamento round-robin 
simples entre os processos de usuário concorrentes. Espera-se que as tarefas, os drivers e os 
servidores sejam executados até serem bloqueados e recebam quanta grandes, mas se forem 
executados por tempo demais, eles também poderão ser preemptados. Não se espera que isso 
aconteça com muita fregiiência, mas é um mecanismo para impedir que um processo de alta 
prioridade com problema bloqueie o sistema. Um processo que impeça outros processos de 
executar também pode ser movido temporariamente para uma fila de prioridade mais baixa. 


Suporte do núcleo dependente de hardware 


Várias funções escritas em C são, contudo, específicas do hardware. Para facilitar a transfe- 
rência do MINIX 3 para outros sistemas, essas funções foram isoladas nos arquivos discu- 
tidos nesta seção, exception.c, i8259.c e protect.c, em vez de serem incluídas nos mesmos 
arquivos com o código de nível superior que suportam. 

Exception.c contém a rotina de tratamento de exceção, exception (linha 8012), que é 
chamada (como exception) pela parte em linguagem assembly do código de tratamento de 
exceção em mpx386.s. As exceções oriundas de processos de usuário são convertidas em 
sinais. Espera-se que os usuários cometam erros em seus próprios programas, mas uma ex- 
ceção gerada pelo sistema operacional indica que algo está seriamente errado e causa uma 
situação de pânico. O array ex data (linhas 8022 a 8040) determina a mensagem de erro a ser 
impressa em caso de pânico ou o sinal a ser enviado para um processo de usuário para cada 
exceção. Anteriormente, os processadores Intel não geravam todas as exceções e o terceiro 
campo em cada entrada indica o modelo de processador mínimo capaz de gerar cada uma de- 
las. Esse array fornece um resumo interessante da evolução da família Intel de processadores 
nos quais o MINIX 3 foi implementado. Na linha 8065, uma mensagem diferente é impressa, 
caso um pânico resulte de uma interrupção não esperada do processador em uso. 


Suporte para interrupção dependente de hardware 


As três funções em i8259.c são usadas durante a inicialização do sistema para inicializar os 
chips controladores de interrupção Intel 8259. A macro da linha 8119 define uma função fic- 
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tícia (a função real é necessária apenas quando o MINIX 3 é compilado para uma plataforma 
Intel de 16 bits). Intr init (linha 8124) inicializa os controladores. Duas etapas garantem que 
nenhuma interrupção ocorra antes que toda a inicialização esteja terminada. Primeiramente, 
intr disable é chamada na linha 8134. Essa é uma chamada em linguagem C para uma função 
em linguagem assembly na biblioteca que executa uma única instrução, cli, a qual desativa o 
atendimento de interrupções pela CPU. Então, em cada controlador de interrupção, é escrito 
uma seqiiência de bytes nos registradores de controle, cujo efeito é desabilitar o atendimento 
dos controladores aos sinais entrada externos. O byte escrito na linha 8145 é composto por 
todos os bits com valores iguais a um, exceto um, o que a entrada em cascata do controlador 
escravo para o controlador mestre (veja a Figura 2-39). Um valor zero permite o atendimento 
da interrupção associado àquela entrada; um valor um, desabilita. O byte escrito no controla- 
dor secundário na linha 8151 é todo composto por valores um. 

Uma tabela armazenada no chip controlador de interrupção 18259 gera um índice de 8 
bits que a CPU utiliza para localizar o descritor de interrupção correto para cada entrada de 
interrupção possível (os sinais no lado direito da Figura 2-39). Isso é configurado pela BIOS 
durante a inicialização do computador e quase todos esses valores podem ser mantidos como 
estão. Quando os drivers que usam de interrupções são inicializados, alterações podem ser 
feitas onde for necessário. Cada driver pode então pedir para que um bit seja reativado no 
chip controlador de interrupção, para permitir sua própria entrada de interrupção. O argu- 
mento mine de intr. init é usado para determinar se o MINIX 3 está sendo inicializado ou 
desligado. Essa função pode ser usada tanto para inicializar na partida como para restaurar as 
configurações da BIOS, quando o MINIX 3 é desligado. 

Depois que a inicialização do hardware terminar, a última etapa em intr. init é copiar os 
vetores de interrupção da BIOS na tabela de vetores do MINIX 3. 

A segunda função em 8259.c é put irg handler (linha 8162). Na inicialização, put irg . 
handler é chamada para cada processo que deve responder a uma interrupção. Isso coloca o en- 
dereço da rotina de tratamento na tabela de interrupção, irg handlers, definida como EXTERN 
em glo.h. Nos computadores modernos, 15 linhas de interrupção nem sempre são suficientes 
(pois pode haver mais do que 15 dispositivos de E/S); portanto, talvez dois dispositivos de E/S 
precisem compartilhar uma linha de interrupção. Isso não ocorrerá com nenhum dos disposi- 
tivos básicos suportados pelo MINIX 3, como descrito neste texto, mas quando interfaces de 
rede, placas de som ou dispositivos de E/S mais esotéricos forem suportados, talvez eles pre- 
cisem compartilhar linhas de interrupção. Para possibilitar isso, a tabela de interrupção não é 
apenas uma tabela de endereços. Irg handlers/NR IRQ VECTORS] é um array de ponteiros 
para estruturas irg hook, um tipo definido em kernel/type.h. Essas estruturas contêm um cam- 
po que é um ponteiro para outra estrutura do mesmo tipo; portanto, pode ser construída uma 
lista encadeada, começando com um dos elementos de irg handlers. Put irg handler adicio- 
na uma entrada em uma dessas listas. O elemento mais importante dessa entrada é um ponteiro 
para uma rotina de tratamento de interrupção (interrupt handler), a função a ser executada 
quando uma interrupção é gerada, por exemplo, quando a E/S solicitada tiver terminado. 

Alguns detalhes de put irg handler merecem ser mencionados. Observe a variável id, 
que é configurada como 1 imediatamente antes do início do laço while que percorre a lista 
encadeada (linhas 8176 a 8180). Sempre que passa pelo laço, id é deslocada 1 bit para a es- 
querda. O teste na linha 8181 limita o comprimento do encadeamento ao tamanho de id, ou 
seja, 32 rotinas de tratamento para um sistema de 32 bits. No caso normal, a varredura vai até 
o final da lista de encadeamento, onde uma nova rotina de tratamento pode ser posta. Quando 
isso é feito, id também é armazenada no campo de mesmo nome no novo item do encadea- 
mento. Put irg handler também ativa um bit na variável global irg use, para registrar que 
existe uma rotina de tratamento para essa IRQ. 
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Se você entendeu completamente o objetivo de projeto do MINIX 3 de colocar drivers 
de dispositivo em espaço de usuário, a discussão anterior sobre como as rotinas de tratamento 
de interrupção são chamadas poderá ter lhe deixado ligeiramente confuso. Os endereços de 
rotina de tratamento de interrupção armazenados nas estruturas de gancho não podem ser 
úteis, a menos que apontem para funções dentro do espaço de endereçamento do núcleo. O 
único dispositivo orientado a interrupção em espaço de endereçamento do núcleo é o relógio. 
E quanto aos drivers de dispositivo que possuem seus próprios espaços de endereçamento? 

A resposta é: a tarefa de sistema trata disso. Na verdade, essa é a resposta para a maioria 
das perguntas a respeito da comunicação entre o núcleo e os processos em espaço de usuário. 
Um driver de dispositivo em espaço de usuário que deve ser orientado a interrupção faz uma 
chamada sys irqgctl para a tarefa de sistema, quando precisa registrar uma rotina de tratamento 
de interrupção. Então, a tarefa de sistema chama put irg handler, mas em vez do endereço 
de uma rotina de tratamento de interrupção no espaço de endereçamento do driver, o ende- 
reço de generic handler, parte da tarefa de sistema, é armazenado no campo da rotina de 
tratamento de interrupção. O campo de número do processo na estrutura de gancho é usado 
por generic handler para localizar a entrada da tabela priv para o driver e o bit no mapa de 
bits de interrupções pendentes do driver, correspondente à interrupção, é ativado. Então, ge- 
neric handler envia uma notificação para o driver. A notificação é identificada como sendo 
de HARDWARE e o mapa de bits das interrupções pendentes do driver é incluído na mensa- 
gem. Assim, se um driver precisar responder às interrupções de mais de uma fonte, ele po- 
derá saber qual é o responsável pela notificação corrente. Na verdade, como o mapa de bits é 
enviado, uma única notificação fornece informações sobre todas as interrupções pendentes do 
driver. Outro campo na estrutura de gancho se refere à política, que determina se a interrup- 
ção deve ser reativada imediatamente ou se deve permanecer desativada. Neste último caso, 
ficará por conta do driver fazer uma chamada de núcleo sys irgenable, quando o serviço da 
interrupção corrente tiver terminado. 

Um dos objetivos de projeto do MINIX 3 é suportar a reconfiguração de dispositivos 
de E/S em tempo de execução. A função seguinte, rm irg handler, remove uma rotina de 
tratamento, uma etapa necessária, caso um driver de dispositivo precise ser removido e, pos- 
sivelmente, substituído por outro. Sua ação é exatamente oposta à de put irg handler. 

A última função nesse arquivo, intr handle (linha 8221), é chamada a partir das macros 
hwint master e hwint slave que vimos em mpx386.s. O elemento do array de mapas de bits 
irg actids correspondente à interrupção que está sendo atendida é usado para monitorar o 
status corrente de cada rotina de tratamento em uma lista. Para cada função na lista, intr. han- 
dle ativa o bit correspondente em irg actids e chama a rotina de tratamento. Se uma rotina 
de tratamento não tem nada para fazer ou se termina seu trabalho imediatamente, ela retorna 
true e o bit correspondente em irg actids é limpo. O mapa de bits completo de uma interrup- 
ção, considerado como um valor inteiro, é testado perto do final das macros hwint master e 
hwint. slave para determinar se essa interrupção pode ser reativada antes que outro processo 
seja reiniciado. 


Suporte para o modo protegido da Intel 


Protect.c contém rotinas relacionadas à operação de modo protegido dos processadores Intel. 
A Tabela Global de Descritores (Global Descriptor Table - GDT), as Tabelas de Descri- 
tores Locais (Local Descriptor Table — LDT) e a Tabela de Descritores de Interrupção 
(Interrupt Descriptor Table — IDT), todas localizadas na memória, fornecem acesso pro- 
tegido aos recursos do sistema. A GTD e a IDT são apontadas por registradores especiais 
dentro da CPU e as entradas de GDT apontam para LDTs. A GDT está disponível para todos 
os processos e contém descritores de segmento para regiões da memória usadas pelo sistema 
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operacional. Normalmente, existe uma única LDT para cada processo, contendo descritores 
de segmento para as regiões da memória utilizadas pelo processo. Os descritores são estru- 
turas de 8 bytes com vários componentes, mas as partes mais importantes de um descritor 
de segmento são os campos que descrevem o endereço de base e o limite de uma região da 
memória. A IDT também é composta de descritores de 8 bytes, sendo a parte mais importante 
o endereço do código a ser executado quando a interrupção correspondente for ativada. 

Cstart, em start.c, chama prot init (linha 8368), que configura a GDT nas linhas 8421 
a 8438. A BIOS do IBM PC exige que ela seja ordenada de certa maneira e todos os índices 
para ela são definidos em protect.h. O espaço para a LTD de cada processo é alocado na 
tabela de processos. Cada uma contém dois descritores, para um segmento de código e para 
um segmento de dados — lembre-se de que estamos discutindo aqui os segmentos definidos 
por hardware; eles não são os mesmos segmentos gerenciados pelo sistema operacional, que 
considera o segmento de dados definido pelo hardware como subdividido em segmentos de 
dados e de pilha. Nas linhas 8444 a 8450, são construídos descritores para cada LDT na GTD. 
As funções init dataseg e init codeseg construíram esses descritores. As entradas nas LDT's 
em si são inicializadas quando o mapa de memória de um processo é alterado (isto é, quando 
é feita uma chamada de sistema exec). 

Outra estrutura de dados de processador que precisa de inicialização é o Segmento de 
Estado de Tarefa (Task State Segment — TSS). A estrutura é definida no início desse arquivo 
(linhas 8325 a 8354) e fornece espaço para armazenamento de registradores do processador 
e outras informações que devem ser salvas quando é feita uma troca de tarefa. O MINIX 3 
utiliza apenas os campos que definem onde uma nova pilha deve ser construída quando ocor- 
rer uma interrupção. A chamada para init dataseg na linha 8460 garante que ela possa ser 
localizada usando a GDT. 

Para entender como o MINIX 3 funciona no nível mais baixo, talvez o mais importante 
seja compreender como as exceções, interrupções de hardware ou instruções int <nnn> levam 
à execução das várias partes do código que foram escritas para atendê-las. Esses eventos são 
processados por meio da tabela de descritores de interrupção. O array gate table (linhas 
8383 a 8418) é inicializado pelo compilador com os endereços das rotinas que tratam de 
exceções e interrupções de hardware e, então, é usado no laço das linhas 8464 a 8468 para 
inicializar essa tabela, usando chamadas para a função int gate. 

Existem bons motivos para o modo como os dados são estruturados nos descritores, 
baseados nos detalhes do hardware e na necessidade de manter a compatibilidade entre os 
processadores mais avançados e o processador 286 de 16 bits. Felizmente, normalmente po- 
demos deixar esses detalhes para os projetistas de processador da Intel. De modo geral, a 
linguagem C nos permite evitar os detalhes. Entretanto, na implementação de um sistema 
operacional real, os detalhes devem ser examinados em algum ponto. A Figura 2-44 mostra 
a estrutura interna de um tipo de descritor de segmento. Note que o endereço de base, que 
os programas C podem ser referir como um inteiro sem sinal de 32 bits simples, é dividido 
em três partes, duas das quais são divididos em diversos valores de 1, 2 e 4 bits. O limite, um 
valor de 20 bits, é armazenado em duas partes separadas, uma de 16 e outra de 4 bits. O limite 
é interpretado como um número de bytes ou como um número de páginas de 4096 bytes, 
com base no valor do bit G (de granularidade). Outros descritores, como aqueles usados para 
especificar como as interrupções são manipuladas, têm estruturas diferentes, mas igualmente 
complexas. Discutiremos essas estruturas com mais detalhes no Capítulo 4. 

A maior parte das outras funções definidas em protect.c é dedicada à conversão entre 
as variáveis usadas nos programas em C e as formas horríveis que esses dados assumem nos 
descritores legíveis pela máquina, como os que aparecem na Figura 2-44. Init codeseg (linha 
8477) e init dataseg (linha 8493) têm operação semelhante e são usadas para converter os pa- 
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Figura 2-44 O formato de um descritor de segmento Intel. 


râmetros passados a elas em descritores de segmento. Cada uma delas, por sua vez, chama a 
função seguinte, sdesc (linha 8508), para completar a tarefa. É aí que são tratados os detalhes 
desorganizados da estrutura mostrada na Figura 2-44. Init codeseg e init data seg não são 
usadas apenas na inicialização do sistema. Elas também são chamadas pela tarefa de sistema 
quando um novo processo é iniciado, para alocar segmentos de memória para o processo 
utilizar. Seg2phys (linha 8533), chamada apenas a partir de start.c, executa uma operação 
inversa da de sdesc, extraindo o endereço de base de um segmento a partir de de um descri- 
tor de segmento. Phys2seg (linha 8556) não é mais necessária; agora, a chamada de núcleo 
sys segctl trata do acesso aos segmentos de memória remotos; por exemplo, a memória na 
área reservada do PC, entre 640K e 1M. Int gate (linha 8571) executa uma função semelhan- 
te a init codeseg e init dataseg, na construção de entradas para a tabela de descritores de 
interrupção. 

Agora, chegamos a uma função em protect.c, enable iop (linha 8589), que pode fa- 
zer um truque sujo. Ela muda o nível de privilégio das operações de E/S, permitindo que o 
processo corrente execute instruções que lêem e escrevam em portas de E/S. A descrição do 
objetivo da função é mais complicada do que a função em si, que apenas ativa dois bits na 
palavra da entrada da estrutura de pilha do processo que fez a chamada, os quais serão carre- 
gados no registrador de status da CPU na próxima vez que o processo for executado. Não é 
necessária uma função para desfazer isso, pois só se aplicará ao processo que fez a chamada. 
Atualmente, essa função não é utilizada e nenhum método é fornecido para uma função em 
espaço de usuário ativá-la. 

A última função em protect.c é alloc segments (linha 8603). Ela é chamada por 
do newmap. Ela também é chamada pela rotina main do núcleo durante a inicialização. 
Essa definição é muito dependente do hardware. Ela pega as atribuições de segmento que 
são gravadas em uma entrada da tabela de processos e manipula os registradores e descri- 
tores utilizados pelo processador Pentium para suportar segmentos protegidos no nível do 
hardware. Múltiplas atribuições, como as das linhas 8629 a 8633, são uma característica 
da linguagem C. 


2.6.12 Utilitários e a biblioteca do núcleo 


Finalmente, o núcleo tem uma biblioteca de funções de suporte escritas em linguagem as- 
sembly, que são incluídas pela compilação de Klib.s, e alguns programas utilitários, escritos 
em C, no arquivo misc.c. Vamos primeiro ver os arquivos em linguagem assembly. Klib.s 
(linha 8700) é um arquivo pequeno, semelhante a mpx.s, que seleciona a versão específica 
da máquina apropriada com base na definição de WORD SIZE. O código que vamos discutir 
está em klib386.s (linha 8800). Ele contém cerca de duas dezenas de rotinas utilitárias em 
linguagem assembly, por eficiência ou porque não podem ser escritas em C. 

“Monitor (linha 8844) torna possível retornar para o monitor de inicialização. Do ponto de 
vista do monitor de inicialização, todo o MINIX 3 é apenas uma sub-rotina, e quando o MINIX 
3 é iniciado, um endereço de retorno para o monitor é deixado na pilha do monitor. Monitor 
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precisa apenas restaurar os vários seletores de segmento e o ponteiro de pilha que foi salvo 
quando o MINIX 3 foi iniciado e, então, retornar como se fosse qualquer outra sub-rotina. 

Int86 (linha 8864) suporta chamadas da BIOS. A BIOS é usada para fornecer drivers de 
disco alternativos, os quais não serão descritos aqui. Int$6 transfere o controle para o moni- 
tor de inicialização, o qual gerencia uma transferência do modo protegido para o modo real 
para executar uma chamada da BIOS e, então, uma transferência para o modo protegido para 
voltar ao MINIX 3 de 32 bits. O monitor de inicialização também retorna o número de tiques 
de relógio contados durante a chamada da BIOS. O modo como isso é usado será visto na 
discussão sobre a tarefa de relógio. 

Embora phys copy (veja a seguir) pudesse ter sido usada para copiar mensagens, foi 
fornecida para esse propósito, cp mess (linha 8952), uma função especializada mais rápida. 
Ela é chamada por 


cp mess(source, src clicks, src offset, dest clicks, dest offset); 


onde source é o número de processo do remetente, o qual é copiado no campo m source do 
buffer do destinatário. Tanto o endereço de origem, como o de destino, são especificados 
fornecendo um número de click, normalmente a base do segmento que contém o buffer, e 
um deslocamento a partir desse click. Essa forma de especificar a origem e o destino é mais 
eficiente do que os endereços de 32 bits utilizados por phys copy. 

Exit, exite exit (linhas 9006 a 9008) são definidas porque algumas rotinas de 
biblioteca que poderiam ser utilizadas na compilação do MINIX 3 fazem chamadas para a 
função exit padrão da linguagem C. Sair do núcleo não é um conceito significativo; não há 
nenhum lugar para se ir. Consegiientemente, a função exit padrão não pode ser usada aqui. 
A solução é ativar as interrupções e entrar em um laço infinito. Finalmente, uma operação 
de E/S ou o relógio causará uma interrupção e a operação normal do sistema será retomada. 
O ponto de entrada de ___main (linha 9012) é outra tentativa de lidar com uma ação do 


compilador que, embora possa fazer sentido ao se compilar um programa de usuário, não 
tem nenhum objetivo no núcleo. Ela aponta para uma instrução ret (retorno de sub-rotina) em 
linguagem assembly. 

“Phys insw (linha 9022), phys insb (linha 9047), phys outsw (linha 9072) e 
-phys outsb (linha 9098) dão acesso às portas de E/S que, no hardware Intel, ocupam 
uma porção específica do endereçamento da memória e usam instruções diferentes das de 
leituras e de escrita da memória RAM. As instruções de E/S utilizadas aqui, ins, insb, outs 
e outsb, são projetadas para trabalhar eficientemente com arrays (strings) e palavras de 
16 bits ou bytes de 8 bits. As instruções adicionais em cada função configuram todos os 
parâmetros necessários para mover determinado número de bytes, ou palavras, entre um 
buffer, endereçado fisicamente, e uma porta. Esse método fornece a velocidade necessária 
para atender os discos, que devem ser atendidos mais rapidamente do que poderia ser feito 
com operações de E/S mais simples de um byte ou uma palavra por vez. 

Uma única instrução de máquina pode ativar ou desativar o atendimento da CPU para 
todas as interrupções. Enable irg (linha 9126) e disable irq (linha 9162) são mais compli- 
cadas. Elas trabalham no nível dos chips controladores de interrupção para ativar e desativar 
individualmente interrupções de hardware. 

“Phys copy (linha 9204) é chamada em C por 


phys copy(source address, destination address, bytes); 


e copia um bloco de dados de uma parte da memória física para qualquer parte em outro lu- 
gar. Os dois endereços são absolutos; isto é, o endereço O significa realmente o primeiro byte 
do espaço de endereçamento total e todos os três parâmetros são valores longos sem sinal. 
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Por segurança, toda a memória a ser usada por um programa deve estar totalmente limpa 
dos dados restantes de um programa que a ocupou anteriormente. Isso é feito pela chamada de 
exec do MINIX 3, utilizando, em última análise, a próxima função em klib386.s, phys. memset 
(linha 9248). 

As duas funções seguintes são específicas dos processadores Intel. Mem rdw (linha 
9291) retorna uma palavra de 16 bits a partir de qualquer endereço de memória. O resultado é 
preenchido com zero no registrador eax de 32 bits. A função reset (linha 9307) reconfigura 
o processador. Ela faz isso carregando o registrador da tabela de descritores de interrupção 
do processador com um ponteiro nulo e, então, executando uma interrupção de software. Isso 
tem o mesmo efeito de uma reconfiguração de hardware. 

A função idle task (linha 9318) é chamada quando não há mais nada para fazer. Ela é 
escrita como um laço infinito, mas não é apenas um laço para ocupar a CPU. Idle task tira 
proveito da disponibilidade da instrução hlt, que coloca o processador em um modo de eco- 
nomia de energia até que uma interrupção seja recebida. Entretanto, a instrução hlt é privile- 
giada e executá-la quando o nível de privilégio corrente não é O causa uma exceção. Assim, 
idle task coloca o endereço de uma sub-rotina contendo uma instrução hlt e, depois, chama 
levelO (linha 9322). Esta função recupera o endereço da sub-rotina halt e o copia em uma área 
de armazenamento reservada (declarada em glo.h e reservada realmente em table.c). 

_Level0 trata o endereço que for previamente carregado nessa área como a parte fun- 
cional de uma rotina de serviço de interrupção a ser executada com o nível de permissão mais 
privilegiado, o nível zero. 

As duas últimas funções são read tsc e read flags. A primeira lê um registrador da 
CPU que executa uma instrução em linguagem assembly conhecida como rdtsc, contador de 
indicação de tempo de leitura. Ela conta ciclos da CPU e serve para efeitos de benchmark ou 
para depuração. Essa instrução não é suportada pelo montador do MINIX 3 e é gerada pela 
codificação do código de operação em hexadecimal. Finalmente, read flags lê os flags do 
processador e os retorna como uma variável em C. O programador estava cansado e o comen- 
tário sobre o objetivo dessa função está incorreto. 

O último arquivo que consideraremos neste capítulo é utility.c, que fornece três funções 
importantes. Quando algo dá completamente errado no núcleo, panic (linha 9429) é ativada. 
Ela imprime uma mensagem e chama prepare. shutdown. Quando o núcleo precisa imprimir 
uma mensagem, ele não pode usar a instrução printf padrão da biblioteca; portanto, uma 
instrução kprintf especial é definida aqui (linha 9450). A gama completa de opções de for- 
matação disponíveis na versão da biblioteca não é necessária aqui, mas grande parte da fun- 
cionalidade está disponível. Como o núcleo não pode usar o sistema de arquivos para acessar 
um arquivo ou um dispositivo, ele passa cada caractere para outra função, kputc (linha 9525), 
a qual insere cada caractere em um buffer. Posteriormente, quando kputc recebe o código 
END OF KMESS, ela informa ao processo que manipula tais mensagens. Isso está definido 
em include/minix/config.h e pode ser o driver de log ou o driver de console. Se for o driver de 
log, a mensagem será passada para o console também. 


A TAREFA DE SISTEMA NO MINIX 3 


Uma conseqiiência de tornar os principais componentes do sistema em processos indepen- 
dentes fora do núcleo é que eles são proibidos de fazer E/S real, manipular tabelas do núcleo e 
fazer outras coisas normalmente realizadas pelas funções do sistema operacional. Por exem- 
plo, a chamada de sistema fork é manipulada pelo gerenciador de processos. Quando um novo 
processo é criado, o núcleo precisa saber a respeito dele para programar sua execução. Como 
o gerenciador de processos pode avisar o núcleo? 
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A solução para esse problema é ter um núcleo que ofereça um conjunto de serviços para 
os drivers e servidores. Esses serviços, que não estão disponíveis para processos de usuário 
normais, permitem que os drivers e servidores façam E/S real, acessem tabelas do núcleo e 
façam outras coisas necessárias, tudo sem estar dentro do núcleo. 

Esses serviços especiais são manipulados pela tarefa de sistema, que é mostrada na 
camada 1 da Figura 2-29. Embora ela seja compilada no programa binário do núcleo, é na 
verdade um processo separado e tem sua execução programada como tal. O papel da tarefa 
de sistema é aceitar todos os pedidos de serviços especiais do núcleo feitos pelos drivers e 
servidores e executá-los. Como a tarefa de sistema faz parte do espaço de endereçamento do 
núcleo, faz sentido estudá-la aqui. 

Anteriormente neste capítulo, vimos um exemplo de serviço fornecido pela tarefa de 
sistema. Na discussão sobre o tratamento de interrupções, descrevemos como um driver de 
dispositivo em espaço de usuário utiliza sys irqctl para enviar uma mensagem para a tarefa 
de sistema solicitando a instalação de uma rotina de tratamento de interrupção. Um driver 
em espaço de usuário não pode acessar a estrutura de dados do núcleo, onde são colocados 
os endereços das rotinas de serviço de interrupção, mas a tarefa de sistema pode fazer isso. 
Além disso, como a rotina do serviço de interrupção também precisa estar no espaço de en- 
dereçamento do núcleo, o endereço armazenado é o de uma função fornecida pela tarefa de 
sistema, generic handler. Essa função responde a uma interrupção enviando uma mensagem 
de notificação para o driver de dispositivo. 

Este é um bom lugar para esclarecer alguma terminologia. Em um sistema operacional 
convencional, com um núcleo monolítico, o termo chamada de sistema é usado para se re- 
ferir a qualquer solicitação de serviços fornecidos pelo núcleo. Em um sistema operacional 
moderno do tipo UNIX, o padrão POSIX descreve as chamadas de sistema disponíveis para 
os processos. Naturalmente, podem existir algumas extensões não padronizadas para o PO- 
SIX, e um programador que a esteja usando geralmente o fará como referência a uma função 
definida em bibliotecas da linguagem C, as quais podem fornecer uma interface de progra- 
mação fácil de usar. Além disso, às vezes, funções de biblioteca diferentes, que parecem para 
o programador como sendo “chamadas de sistema” distintas, na verdade utilizam o mesmo 
acesso ao núcleo. 

No MINIX 3 o panorama é diferente: os componentes do sistema operacional são exe- 
cutados em espaço de usuário, embora tenham privilégios especiais como processos de sis- 
tema. Ainda usaremos o termo “chamada de sistema” para todas as chamadas de sistema 
definidas pelo POSIX (e algumas extensões do MINIX) listadas na Figura 1-9, mas os pro- 
cessos de usuário não solicitam serviços diretamente do núcleo. No MINIX 3, as chamadas 
de sistema feitas por processos de usuário são transformadas em mensagens para proces- 
sos servidores. Os processos servidores se comunicam entre si, com drivers de dispositivo 
e com o núcleo, por meio de mensagens. O assunto desta seção, a tarefa de sistema, recebe 
todas as requisições de serviços do núcleo. Vagamente falando, poderíamos chamar essas 
requisições de chamadas de sistema, mas para sermos mais exatos, vamos nos referir a elas 
como chamadas de núcleo. As chamadas de núcleo não podem ser feitas por processos de 
usuário. Em muitos casos, uma chamada de sistema originada por um processo de usuário 
resulta em uma chamada de núcleo com um nome semelhante sendo feita por um servidor. 
Isso sempre acontece porque alguma parte do serviço que está sendo solicitado só pode ser 
manipulada pelo núcleo. Por exemplo, uma chamada de sistema fork, feita por um processo 
de usuário, vai para o gerenciador de processos, o qual realiza parte do trabalho. Mas um fork 
exige alterações na parte do núcleo referente à tabela de processos e, para completar a ação, 
o gerenciador de processos faz uma chamada sys fork para a tarefa de sistema, a qual pode 
manipular dados no espaço de endereçamento do núcleo. Nem todas as chamadas de núcleo 
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têm uma conexão direta com uma única chamada de sistema. Por exemplo, existe uma cha- 
mada de núcleo, sys_devio, para ler ou escrever em portas de E/S. Essa chamada de núcleo 
vem de um driver de dispositivo. Mais da metade de todas as chamadas de sistema listadas na 
Figura 1-9 poderia resultar em um driver de dispositivo sendo ativado e fazendo uma ou mais 
chamadas de sys_devio. 

Tecnicamente falando, uma terceira categoria de chamadas (além das chamadas de sis- 
tema e das chamadas de núcleo) deve ser distinguida. As primitivas de mensagem utilizadas 
para comunicação entre processos, como send, receive e notify, podem ser consideradas como 
chamadas de sistema. Provavelmente nos referenciamos a elas desse modo em vários lugares 
neste livro — afinal, elas chamam o sistema. Mas elas devem ser corretamente denominadas 
de algo diferente de chamadas de sistema e de chamadas de núcleo. Outros termos podem 
ser usados. Às vezes é usado o termo primitiva IPC, assim como trap, e ambos podem ser 
encontrados em alguns comentários no código-fonte. Você pode considerar uma primitiva de 
mensagem como a onda portadora em um sistema de comunicação via rádio. Normalmente, 
a modulação é necessária para tornar uma onda de rádio útil; o tipo da mensagem e outros 
componentes de uma estrutura de mensagem permitem que a chamada da mensagem transmi- 
ta informações. Em alguns casos, uma onda de rádio não-modulada é útil; por exemplo, um 
radiofarol para guiar aviões em um aeroporto. Isso é análogo à primitiva de mensagem notify, 
que transmite poucas informações, além de sua origem. 


Visão geral da tarefa de sistema 


A tarefa de sistema aceita 28 tipos de mensagens, mostrados na Figura 2-45. Cada um deles 
pode ser considerado uma chamada de núcleo, embora, conforme veremos, em alguns casos 
existam várias macros definidas com nomes diferentes, todas resultando em apenas um dos 
tipos de mensagem mostrados na figura. E, ainda em outros casos, mais de um dos tipos de 
mensagem da figura é manipulado por uma única função que faz o trabalho. 

O programa principal da tarefa de sistema é estruturado como as outras tarefas. Após 
fazer a inicialização necessária, ele é executado um laço. Ele recebe uma mensagem, despa- 
cha para a função de serviço apropriada e, então, envia uma resposta. Algumas funções de 
suporte gerais são encontradas no arquivo principal, system.c, mas o laço principal vai para 
uma função em um arquivo separado no diretório kernel/system/ para processar cada chama- 
da de núcleo. Veremos como isso funciona e o motivo dessa organização quando discutirmos 
a implementação da tarefa de sistema. 

Primeiramente, descreveremos brevemente a função de cada chamada de núcleo. Os 
tipos de mensagem na Figura 2-45 caem em várias categorias. Os primeiros estão envolvidos 
com o gerenciamento de processos. Sys fork, sys exec, sys exite sys trace estão, intima- 
mente relacionadas com as chamadas de sistema padrão do POSIX. Embora nice não seja 
uma chamada de sistema exigida pelo POSIX, em última análise o comando resulta em uma 
chamada de núcleo sys nice para alterar a prioridade de um processo. O único tipo desse 
grupo que provavelmente não é familiar é sys privctl. Ela é usada pelo servidor de reencar- 
nação (RS), o componente do MINIX 3 responsável por converter processos iniciados como 
processos de usuário normais em processos de sistema. Sys privctl altera os privilégios de um 
processo, por exemplo, para permitir que ele faça chamadas de núcleo. Sys privctl é utilizada 
quando drivers e servidores que não fazem parte da imagem de boot são iniciados pelo script 
fetc/rc. Os drivers do MINIX 3 também podem ser iniciados (ou reiniciados) a qualquer mo- 
mento; quando isso é feito, são necessárias alterações de privilégio. 

O próximo grupo de chamadas de núcleo está relacionado com os sinais. Sys kill está 
relacionada com a chamada de sistema kill acessível para o usuário (e foi denominada de 
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Tipo de mensagem De Significado 

sys fork PM Um processo fez um fork 

Sys exec PM Configura o ponteiro de pilha após a chamada de EXEC 

sys exit PM Um processo terminou 

sys nice PM Configura a prioridade para escalonamento 

sys privcil SR Configura ou altera privilégios 

sys trace PM Executa uma operação da chamada de PTRACE 

sys kill PM,FS, TTY | Envia um sinal para um processo após a chamada de 
KILL 

sys getksig PM O PM está verificando a existência de sinais pendentes 

sys endksig PM O PM terminou o processamento do sinal 

sys sigsend PM Envia um sinal para um processo 

sys. sigreturn PM Limpeza após a conclusão de um sinal 

sys iractl Drivers Ativa, desativa ou configura interrupção 

sys. devio Drivers Lê ou escreve em uma porta de E/S 

sys sdevio Drivers Lê ou escreve string na porta de E/S 

sys vdevio Drivers Executa um vetor de requisições de E/S 

sys int86 Drivers Realiza uma chamada de BIOS no modo real 

Sys newmap PM Configura o mapa de memória de um processo 

sys segcil Drivers Adiciona segmento e obtém o seletor (acesso remoto a 
dados) 

sys memset PM Escreve caracteres na área de memória 

sys umap Drivers Converte endereço virtual em endereço físico 

SyS. vircopy FS, Drivers Copia usando endereçamento virtual puro 

sys physcopy Drivers Copia usando endereçamento físico 

SyS virvcopy Qualquer um | Vetor de requisições de VCOPY 

sys physvcopy Qualquer um | Vetor de requisições de PHYSCOPY 

sys times PM Obtém os tempos de funcionamento e de processo 

sys setalarm PM, FS, Escalona a execução de um alarme síncrono 

Drivers 
sys abort PM, TTY Pânico: o MINIX é incapaz de continuar 
sys getinfo Qualquer um | Requisição de informação do sistema 


Figura 2-45 Os tipos de mensagem aceitos pela tarefa de sistema. “Qualquer um” significa 
qualquer processo de sistema; os processos de usuário não podem chamar a tarefa de sistema 
diretamente. 


forma errada). As outras chamadas nesse grupo, sys getksig, sys endksig, sys sigsend e 
sys sigreturn são usadas pelo gerenciador de processos para obter ajuda do núcleo no trata- 
mento de sinais. 

As chamadas de núcleo sys irqctl, sys devio, sys sdevio e sys vdevio são exclusivas 
do MINIX 3. Elas fornecem o suporte necessário para drivers de dispositivo em espaço de 
usuário. Mencionamos sys irgctl no início desta seção. Uma de suas funções é configurar 
uma rotina de tratamento de interrupção de hardware e ativar interrupções em nome de um 
driver em espaço de usuário. Sys devio permite que um driver em espaço de usuário peça 
para que a tarefa de sistema leia ou escreva em uma porta de E/S. Obviamente, isso é funda- 
mental; também deve ser evidente que ela envolve mais sobrecarga do que seria o caso se o 
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driver estivesse sendo executado em espaço de núcleo. As duas chamadas de núcleo seguintes 
oferecem um nível mais alto de suporte para dispositivo de E/S. Sys sdevio pode ser usada 
quando uma segiiência de bytes ou palavras, isto é, uma string, deve ser lida ou escrita em 
um único endereço de E/S, como pode acontecer ao se acessar uma porta serial. Sys vdevio 
é usada para enviar um vetor de requisições de E/S para a tarefa de sistema. Um vetor quer 
dizer uma série de pares (porta, valor). Anteriormente neste capítulo, descrevemos a função 
intr init, que inicializa os controladores de interrupção Intel 18259. Nas linhas 8140 a 8152, 
uma segiiência de instruções escreve uma série de valores de byte. Para cada um dos dois 
chips 18259, existe uma porta de controle que configura o modo e outra que recebe uma série 
de quatro bytes na sequência de inicialização. Naturalmente, esse código é executado no nú- 
cleo; portanto, nenhum suporte da tarefa de sistema é necessário. Mas se isso estivesse sendo 
feito por um processo em espaço de usuário, uma única mensagem passando o endereço para 
um buffer contendo 10 pares (porta, valor) seria muito mais eficiente do que 10 messagens 
passando, cada uma, um único endereço de porta e um valor a ser escrito. 

As três chamadas de núcleo seguintes mostradas na Figura 2-45 envolvem a memória 
de maneiras distintas. A primeira, sys newmap, é chamada pelo gerenciador de processos 
sempre que a memória utilizada por um processo é alterada para permitir que a tabela de 
processos, pertencente ao núcleo, possa ser atualizada. Sys segctl e sys memset fornecem 
uma maneira segura de dar a um processo acesso à memória fora de seu próprio espaço de 
endereçamento de dados. A área de memória de 0xa0000 a Oxfffff é reservada para dispositi- 
vos de E/S, conforme mencionamos na discussão sobre a inicialização do sistema MINIX 3. 
Alguns dispositivos utilizam parte dessa região da memória para E/S—por exemplo, as pla- 
cas de vídeo esperam que os dados a serem exibidos sejam escritos na memória da placa que 
é mapeada nessa zona de endereçamento. Sys segcil é utilizada por um driver de dispositivo 
para obter um seletor de segmento que permitirá a ela endereçar memória nesse intervalo. 
A outra chamada, sys memset, é usada quando um servidor deseja escrever dados em uma 
área da memória que não pertence a ele. Ela é usada pelo gerenciador de processos para zerar 
a memória quando um novo processo é iniciado evitando assim que o novo processo leia os 
dados deixados por outro processo. 

O próximo grupo de chamadas de núcleo serve para copiar memória. Sys umap con- 
verte endereços virtuais em endereços físicos. Sys vircopy e sys physcopy copiam regiões 
da memória, usando endereços virtuais ou endereços físicos. As duas chamadas seguintes, 
SyS virvcopy e sys physvcopy, são versões das duas anteriores que usam vetores. Assim 
como acontece com um vetor de requisições de E/S, elas permitem fazer uma requisição para 
a tarefa de sistema solicitando uma série de operações de cópia de memória. 

Sys. times, obviamente, tem a ver com tempo e corresponde à chamada de sistema times 
do POSIX. Sys setalarm está relacionada com a chamada de sistema alarm do POSIX, mas 
o parentesco é distante. A chamada do POSIX é manipulada principalmente pelo gerenciador 
de processos, o qual mantém um conjunto de temporizadores (timers) em nome de processos 
de usuário. O gerenciador de processos utiliza uma chamada de núcleo sys setalarm quando 
precisa ter um temporizador configurado no núcleo para seu uso. Isso é feito apenas quando 
há uma mudança no início da fila gerenciada pelo PM e não segue necessariamente cada cha- 
mada alarm de um processo de usuário. 

As duas últimas chamadas de núcleo listadas na Figura 2-45 servem para controle do 
sistema. Sys abort pode ser originada no gerenciador de processos, após um pedido normal de 
desligamento do sistema (shutdown) ou após um pânico. Ela também pode originar do driver de 
dispositivo tty, em resposta a um usuário pressionando a combinação de teclas Ctrl-Alt-Del. 

Finalmente, sys getinfo é uma panacéia que trata de uma variedade de requisições de 
informação do núcleo. Na verdade, se você pesquisar os arquivos-fonte em C do MINIX 3, 
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encontrará muito poucas referências a essa chamada com seu próprio nome. Mas se você pes- 
quisar os diretórios de cabeçalho, encontrará no mínimo 13 macros em include/minix/syslib.h 
que dão outro nome para Sys getinfo. Um exemplo é 


sys getkinfo(dst) sys getinfo(GET | KINFO, dst, 0,0,0) 


que é usada para retornar a estrutura kinfo (definida em include/minix/type.h, nas linhas 2875 
a 2893) para o gerenciador de processos, para uso durante a inicialização do sistema. A mes- 
ma informação pode ser necessária em outras ocasiões. Por exemplo, o comando de usuário 
ps precisa conhecer a localização no núcleo da tabela de processos para exibir informações 
sobre o status de todos os processos. Ele pede ao PM, que por sua vez utiliza a variante 
sys. getkinfo de sys getinfo para obter a informação. 

Antes de deixarmos esta visão geral dos tipos de chamada de núcleo, devemos mencionar 
que sys getinfo não é a única chamada de núcleo ativada por meio de vários nomes diferen- 
tes definidos como macros em include/minix/syslib.h. Por exemplo, a chamada de sys sdevio 
é normalmente feita por uma das macros sys insb, sys insw, sys outsb ou sys outsw. Os 
nomes foram planejados para tornar fácil ver se a operação é de entrada ou saída, com tipos 
de dados byte ou word. Analogamente, a chamada sys irqctl normalmente é feita por uma 
macro como sys irqenable, sys irqdisable ou uma das várias outras. Tais macros tornam o 
significado mais claro para uma pessoa que esteja lendo o código. Elas também ajudam o 
programador, gerando argumentos constantes automaticamente. 


Implementação da tarefa de sistema 


A tarefa de sistema é compilada a partir de um cabeçalho, system.h, e de um arquivo-fonte em 
C, system.c, no diretório principal kernel/. Além disso, existe uma biblioteca especializada, 
construída a partir dos arquivos-fonte em um subdiretório, kernel/system/. Há um motivo 
para essa organização. Embora o MINIX 3, conforme descrevemos aqui, seja um sistema 
operacional de propósito geral, ele também é potencialmente útil para propósitos especiais, 
como o suporte incorporado em um dispositivo portátil. Nesses casos, uma versão simplifi- 
cada do sistema operacional poderia ser adequada. Por exemplo, um dispositivo sem disco 
talvez não precise de um sistema de arquivos. Vimos em kernel/config.h que a compilação de 
chamadas de núcleo pode ser ativada e desativada seletivamente. Ter o código que suporta 
cada chamada de núcleo a partir da ligação de bibliotecas no último estágio de um processo 
de compilação torna mais fácil construir um sistema personalizado. 

Colocar o suporte para cada chamada de núcleo em um arquivo separado simplifica a 
manutenção do software. Mas existe certa redundância entre esses arquivos, e listar todos eles 
acrescentaria 40 páginas neste livro. Assim, listaremos no Apêndice B e descreveremos no 
texto apenas alguns dos arquivos presentes no diretório kernel/system/. Entretanto, todos os 
arquivos estão no CD-ROM e no site web do MINIX 3. 

Começaremos vendo o arquivo de cabeçalho, kernel/system.h (linha 9600). Ele fornece 
protótipos para funções correspondentes à maioria das chamadas de núcleo listadas na Figura 
2-45. Além disso, há um protótipo para do unused, a função ativada caso seja feita uma cha- 
mada de núcleo não suportada. Alguns dos tipos de mensagem da Figura 2-45 correspondem 
às macros definidas aqui. Eles estão nas linhas 9625 a 9630. Esses são casos onde uma única 
função pode manipular mais de uma chamada. 

Antes de examinar o código em system.c, observe a declaração do vetor de chamada 
call vec e a definição da macro map nas linhas 9745 a 9749. Call vec é um array de pontei- 
ros para funções, o qual fornece um mecanismo para acionar a função necessária para aten- 
der uma mensagem em particular, usando o tipo da mensagem (expresso como um número) 
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como índice para o array. Essa é uma técnica que veremos sendo utilizada em outras partes 
do MINIX 3. A macro map é uma maneira conveniente de inicializar um array dessa forma. 
A macro é definida de tal maneira que tentar expandi-la com um argumento inválido resultará 
na declaração de um array com tamanho negativo, o que evidentemente é impossível e cau- 
sará um erro de compilador. 

O nível superior da tarefa de sistema é a função sys task. Após uma chamada para ini- 
cializar um array de ponteiros para funções, sys task é executada em um laço. Ela espera por 
uma mensagem, faz alguns testes para validar a mensagem, desvia para a função que trata da 
chamada correspondente ao tipo da mensagem, possivelmente gerando uma mensagem de 
resposta, e repete o ciclo enquanto o MINIX 3 estiver em execução (linhas 9768 a 9796). Os 
testes consistem em uma verificação da entrada da tabela priv do processo que fez a chama- 
da, para determinar se ele pode fazer esse tipo de chamada e certificar-se de que esse tipo de 
chamada é válido. O desvio para a função que faz o trabalho é feito na linha 9783. O índice 
para o array call vec é o número da chamada, a função chamada é aquela cujo endereço está 
nesse elemento do array, o argumento da função é um ponteiro para a mensagem e o valor de 
retorno é um código de status. Uma função pode retornar o status EDONTREPLY, significan- 
do que nenhuma mensagem de resposta é exigida; caso contrário, uma mensagem de resposta 
será enviada na linha 9792. 

Conforme você pode ter notado na Figura 2-43, quando o MINIX 3 inicia, a tarefa de 
sistema está no início da fila de prioridade mais alta; portanto, faz sentido a função initialize 
da tarefa de sistema inicializar o array de ganchos de interrupção e a lista de temporizadores 
de alarme (linhas 9808 a 9815). Em qualquer caso, conforme observamos anteriormente, a 
tarefa de sistema é usada para ativar interrupções em nome de drivers em espaço de usuário 
que precisam responder às interrupções; portanto, faz sentido ela preparar a tabela. A tarefa 
de sistema é utilizada para configurar temporizadores quando alarmes síncronos são solici- 
tados por outros processos de sistema; portanto, também é apropriado inicializar as listas de 
temporizadores aqui. 

Continuando com a inicialização, nas linhas 9822 a 9824 todas as entradas no array 
call vec são preenchidas com o endereço da função do unused, executada caso seja feita 
uma chamada de núcleo não suportada. Então, o restante do arquivo, nas linhas 9827 a 9867, 
consiste em várias expansões da macro map, cada uma das quais instala o endereço de uma 
função na entrada correta de call vec. 

O restante de system.c consiste em funções que são declaradas como PUBLIC e que 
podem ser usadas por mais de uma das rotinas que atendem as chamadas de núcleo ou por 
outras partes do núcleo. Por exemplo, a primeira dessas funções, get priv (linha 9872), é 
utilizada por do privctl, que suporta a chamada de núcleo sys. privcil. Ela também é chamada 
pelo próprio núcleo, enquanto constrói as entradas da tabela de processos para os processos 
na imagem de boot. O nome talvez engane um pouco. Get priv não recupera informações 
sobre os privilégios já atribuídos, ela encontra uma estrutura priv disponível e a atribui ao 
processo que fez a chamada. Existem dois casos — cada um dos processos de sistema obtém 
sua própria entrada na tabela priv. Se uma entrada não estiver disponível, o processo não po- 
derá se tornar um processo de sistema. Todos os processos de usuário compartilham a mesma 
entrada na tabela. 

Get randomness (linha 9899) é usada para obter números-semente para o gerador de 
números aleatórios, que é implementado como um dispositivo de caracteres no MINIX 3. Os 
processadores da classe Pentium mais recentes incluem um contador de ciclos interno e for- 
necem uma instrução em linguagem assembly que pode lê-lo. Isso será usado se estiver dispo- 
nível; caso contrário será chamada uma função que lê um registrador no chip de relógio. 


CAPÍTULO 2 e PROCESSOS 197 


Send sig gera uma notificação para um processo de sistema após ativar um bit no mapa 
de bits s sig pending do processo a ser sinalizado. O bit é ativado na linha 9942. Note que, 
como o mapa de bits s sig pending faz parte de uma estrutura priv, esse mecanismo só pode 
ser usado para notificar processos de sistema. Todos os processos de usuário compartilham 
uma entrada comum na tabela priv e, portanto, campos como o mapa de bits s sig pending 
não podem ser compartilhados e não são utilizados por processos de usuário. A verificação 
de que o destino é um processo de sistema é feita antes de send sig ser chamada. A chamada 
vem como resultado de uma chamada de núcleo sys kill ou a partir do núcleo, quando kprintf 
está enviando uma string de caracteres. No primeiro caso, o processo que fez a chamada 
determina se o destino é um processo de sistema ou não. No último caso, o núcleo apenas im- 
prime no processo de saída configurado, que é o driver de console ou o driver de log: ambos 
são processos de sistema. 

A função seguinte, cause sig (linha 9949), é chamada para enviar um sinal para um 
processo de usuário. Ela é usada quando uma chamada de núcleo sys. kill tem como alvo um 
processo de usuário. Ela está aqui em system.c porque também pode ser chamada diretamente 
pelo núcleo, em resposta a uma exceção disparada pelo processo de usuário. Assim como 
acontece com send sig, um bit para sinais pendentes deve ser ativado no mapa de bits do 
destinatário, mas para processos de usuário isso não se dá na tabela priv, mas sim na tabela de 
processos. O processo de destino também deve se tornar não apto por meio de uma chamada 
para lock dequeue e seus flags (também na tabela de processos) devem ser atualizados para 
indicar que ele vai ser sinalizado. Então, uma mensagem é enviada — mas não para o processo 
de destino. A mensagem é enviada para o gerenciador de processos, o qual cuida de todos os 
aspectos da sinalização de um processo que podem ser tratados por um processo de sistema 
em espaço de usuário. 

Em seguida, aparecem três funções, todas suportam a chamada de núcleo sys umap. 
Normalmente, os processos tratam com endereços virtuais, relativos à base de um segmento 
em particular. Mas, às vezes, eles precisam conhecer o endereço absoluto (físico) de uma 
região de memória, por exemplo, se for feito uma requisição de cópia entre regiões da me- 
mória pertencentes a dois segmentos diferentes. Existem três modos pelos quais um ende- 
reço de memória virtual pode ser especificado. O modo normal para um processo é relativo 
a um dos segmentos de memória, texto, dados ou pilha, atribuído ao processo e escrito em 
sua entrada na tabela de processos. Neste caso, a solicitação da conversão de uma memória 
virtual em física é feita por uma chamada para umap local (linha 9983). 

O segundo tipo de referência de memória é para uma região da memória que está fora 
das áreas de texto, dados ou pilha alocadas para um processo, mas pela qual o processo tem 
alguma responsabilidade. Exemplos disso são um driver de vídeo ou um driver Ethernet, onde 
a placa de vídeo, ou Ethernet, poderia ter uma região de memória mapeada nos endereços de 
0xa0000 a Oxfffff, que é reservada para dispositivos de E/S. Outro exemplo é o driver de me- 
mória, que gerencia o disco virtual e também pode dar acesso a qualquer parte da memória por 
intermédio dos dispositivos /dev/mem e /dev/kmem. Os pedidos de conversão de tais referên- 
cias de memória, de virtual para física, são tratados por umap remote (linha 10025). 

Finalmente, uma referência de memória pode ser para a memória utilizada pela BIOS. 
Isso é considerado para incluir tanto os 2 KB de memória mais baixos (abaixo de onde o 
MINIX 3 é carregado) como a região de 0x90000 a Oxfffff (que inclui alguma memória RAM 
acima de onde o MINIX 3 é carregado), mais a região reservada para dispositivos de E/S. Isso 
também poderia ser manipulado por umap remote, mas o uso da terceira função, umap bios 
(linha 10047), garante que seja feita uma verificação de que a memória que está sendo refe- 
renciada está realmente nessa região. 
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2.7.3 


A última função definida em system.c é virtual copy (linha 10071). A maior parte dessa 
função é uma instrução switch da linguagem C que utiliza uma das três funções umap * que 
acabamos de descrever, para converter endereços virtuais em endereços físicos. Isso é feito 
tanto para o endereço de origem como para o de destino. A cópia real é feita por uma chama- 
da (na linha 10121) para a rotina em linguagem assembly phys. copy, em klib386.s. 


Implementação da biblioteca de sistema 


Cada uma das funções com um nome da forma do xyz tem seu código-fonte em um arquivo 
em um subdiretório, kernel/system/do xyz.c. No diretório kernel/, o arquivo Makefile contém 
uma linha 


cd system && S(MAKE) -S(MAKEFLAGS) $@ 


a qual faz todos os arquivos em kernel/system/ serem compilados em uma biblioteca, system.a 
no diretório principal kernel/. Quando o controle retorna para o diretório principal do núcleo, 
outra linha no arquivo Makefile faz essa biblioteca local ser buscada e acessada para compor a 
ligação dos arquivos-objeto do núcleo . 

Listamos dois arquivos do diretório kernel/system/no Apêndice B. Eles foram esco- 
lhidos porque representam duas classes gerais de suporte fornecido pela tarefa de sistema. 
Uma categoria de suporte é o acesso às estruturas de dados do núcleo em nome de qual- 
quer processo de sistema em espaço de usuário que precise desse suporte. Vamos descre- 
ver system/do setalarm.c como um exemplo dessa categoria. A outra categoria geral é o 
suporte para chamadas de sistema específicas, gerenciadas principalmente por processos 
em espaço de usuário, mas que precisam executar outras ações em espaço de núcleo. Esco- 
lhemos system/do exec.c como exemplo. 

A chamada de núcleo sys setalarm é bastante parecida com sys irgenable, a qual men- 
cionamos na discussão sobre tratamento de interrupção no núcleo. Sys irgenable configura 
um endereço para uma rotina de tratamento de interrupção a ser chamada quando uma IRQ 
é ativada. A rotina de tratamento é uma função dentro da tarefa de sistema, generic handler. 
Ela gera uma mensagem notify para o processo de driver de dispositivo que deve responder 
à interrupção. System/do setalarm.c (linha 10200) contém código para gerenciar tempori- 
zadores de maneira semelhante ao das interrupções. Uma chamada de núcleo sys setalarm 
inicializa um temporizador para um processo de sistema em espaço de usuário que precisa 
receber um alarme síncrono e fornece uma função a ser chamada para notificar esse proces- 
so quando o temporizador expira. Ela também pode solicitar o cancelamento de um alarme 
agendado anteriormente, passando zero no campo de tempo de expiração de sua mensagem 
de requisição. A operação é simples — nas linhas 10230 a 10232, são extraídas as informações 
da mensagem. Os itens mais importantes são o tempo de expiração e o processo a ser notifi- 
cado. Todo processo de sistema tem sua própria estrutura de temporizador na tabela priv. Nas 
linhas 10237 a 10239, a estrutura de temporizador é localizada e são inseridos o número do 
processo e o endereço de uma função, cause alarm, a ser executada quando o temporizador 
expirar. 

Se o temporizador já estava ativo, sys setalarm retornará o tempo restante na mensagem 
de resposta. Um valor de retorno igual a zero significa que o temporizador não está ativo. Exis- 
tem várias possibilidades a serem consideradas. O temporizador poderia ter sido desativado 
anteriormente — um temporizador é marcado como inativo pelo armazenamento de um valor 
especial, TMR NEVER, em seu campo exp time. No que diz respeito ao código em C, esse é 
apenas um número inteiro grande; portanto, é feito um teste explícito para esse valor, como 
parte da verificação para saber se o tempo de expiração já decorreu. O temporizador poderia 
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indicar um tempo já decorrido. É improvável que isso aconteça, mas é fácil de verificar. O 
temporizador também poderia indicar um tempo no futuro. Nos dois primeiros casos, o valor 
de resposta é zero; caso contrário, o tempo restante é retornado (linhas 10242 a 10247). 

Finalmente, o temporizador é reconfigurado ou configurado. Neste nível, isso é feito 
colocando-se o tempo de expiração desejado no campo correto da estrutura de temporizador 
e chamando-se outra função para fazer o trabalho. É claro que reconfigurar o temporizador 
não exige o armazenamento de um valor. Veremos as funções reset e set em breve, seus có- 
digos estão no arquivo-fonte da tarefa de relógio. Mas, como a tarefa de sistema e a tarefa de 
relógio são compiladas na imagem do núcleo, todas as funções declaradas como PUBLIC são 
acessíveis. 

Há uma outra função definida em do setalarm.c. Trata-se de cause alarm, a função de 
sentinela cujo endereço é armazenado em cada temporizador, para que ela possa ser chamada 
quando o temporizador expirar. Ela é a própria simplicidade — a função gera uma mensagem 
notify para o processo cujo número de processo também é armazenado na estrutura de tem- 
porizador. Assim, o alarme síncrono dentro do núcleo é convertido em uma mensagem para o 
processo de sistema que solicitou um alarme. 

Além disso, note que quando falamos sobre a inicialização de temporizadores ante- 
riormente (e nesta seção também), nos referimos aos alarmes síncronos solicitados pelos 
processos de sistema. Se isso não foi completamente entendido neste ponto e se você está 
se perguntando o que é um alarme síncrono, ou a respeito de temporizadores para processos 
que não são de sistema, essas perguntas serão respondidas na próxima seção, quando discu- 
tirmos a tarefa de relógio. Existem tantas partes interligadas em um sistema operacional, que 
é quase impossível ordenar todos os tópicos de uma maneira que não exija, ocasionalmente, 
uma referência a uma parte que ainda não foi explicada. Isso é particularmente verdade ao se 
discutir uma implementação. Se não estivéssemos tratando com um sistema operacional real, 
provavelmente poderíamos deixar de apresentar detalhes complicados como esse. Quanto a 
isso, uma discussão totalmente teórica dos princípios do sistema operacional provavelmente 
nunca mencionaria uma tarefa de sistema. Em um livro teórico, poderíamos simplesmente dar 
de ombros e ignorar os problemas de fornecer componentes do sistema operacional em espa- 
ço de usuário limitado e do acesso controlado a recursos privilegiados, como interrupções e 
portas de E/S. 

O último arquivo no diretório kernel/system/ que discutiremos em detalhes é do exec.c 
(linha 10300). A maior parte do trabalho da chamada de sistema exec é feita dentro do geren- 
ciador de processos. O gerenciador de processos configura uma pilha para um novo programa, 
contendo os argumentos e o ambiente. Então, ele passa o ponteiro de pilha resultante para o 
núcleo, usando sys exec, que é manipulada por do exec (linha 10618). O ponteiro de pilha é 
configurado na parte do núcleo da tabela de processos e, se o processo que está sendo executa- 
do por exec estiver usando um segmento extra, a função em linguagem assembly phys. memset, 
definida em klib386.s, será chamada para remover todos os dados que possam ter restado do 
uso anterior dessa região da memória (linha 10330). 

Uma chamada de exec causa uma ligeira anomalia. O processo que ativa a chamada en- 
via uma mensagem para o gerenciador de processos e é bloqueado. Para as demais chamadas 
de sistema, a resposta resultante iria desbloqueá-lo. Com exec, não há resposta, pois a ima- 
gem do núcleo recentemente carregada não está esperando uma resposta. Portanto, do exec 
desbloqueia o processo em si, na linha 10333. A linha seguinte torna a nova imagem pronta 
para executar, usando a função lock enqueue que protege contra uma possível condição de 
corrida. Finalmente, a string de comando é salva para que o processo possa ser identificado 
quando o usuário ativar o comando ps ou pressionar uma tecla de função para exibir dados da 
tabela de processos. 
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Para concluirmos nossa discussão sobre a tarefa de sistema, vamos ver sua função no 
tratamento de um serviço operacional típico, fornecendo dados em resposta a uma chamada 
de sistema read. Quando um usuário faz uma chamada de read, o sistema de arquivos verifica 
sua cache para ver se ela tem o bloco necessário. Se não tiver, ele envia uma mensagem para 
o driver de disco apropriado, para carregá-lo na cache. Então, o sistema de arquivos envia 
uma mensagem para a tarefa de sistema, dizendo para que ela copie o bloco no processo de 
usuário. No pior caso, são necessárias 11 mensagens para ler um bloco; no melhor caso, são 
necessárias quatro mensagens. Os dois casos aparecem na Figura 2-46. Na Figura 2-46 (a), 
a mensagem 3 pede para que a tarefa de sistema execute instruções de E/S; 4 é a mensagem 
ACK. Quando ocorre uma interrupção de hardware, a tarefa de sistema informa sobre esse 
evento para o driver que está esperando, com a mensagem 5. As mensagens 6 e 7 são uma re- 
quisição para copiar os dados na cache do sistema de arquivos (FS — File System) e a resposta; 
a mensagem 8 informa ao sistema de arquivos que os dados estão prontos e as mensagens 9 e 
10 são uma requisição para copiar os dados da cache para o usuário e a resposta. Finalmente, 
a mensagem 11 é a resposta para o usuário. Na Figura 2-46 (b), os dados já estão na cache, as 
mensagens 2 e 3 são as requisições para copiá-los no usuário e a resposta. Essas mensagens 
são uma fonte de sobrecarga no MINIX 3 e representam o preço pago pelo projeto altamente 
modular. 


a a jae 
d 


(a) 


Figura 2-46 (a) O pior caso para ler um bloco exige 11 mensagens. (b) O melhor caso para 
ler um bloco exige quatro mensagens. 


As chamadas de núcleo para solicitar cópia de dados provavelmente são as mais utiliza- 
das no MINIX 3. Já vimos a parte da tarefa de sistema que, em última análise, realiza o tra- 
balho, a função virtual_copy. Uma maneira de lidar com parte da ineficiência do mecanismo 
de passagem de mensagens é empacotar várias requisições em uma mensagem. As chamadas 
de núcleo sys_virvcopy e sys_physvcopy fazem isso. O conteúdo de uma mensagem que ativa 
uma dessas chamadas é um ponteiro para um vetor especificando vários blocos a serem co- 
piados entre posições de memória. Ambas são suportadas por do_vcopy, que executa um laço, 


CAPÍTULO 2 e PROCESSOS 201 


2.8 


2.8.1 


extraindo os endereços de origem e destino e comprimentos de bloco, e chamando phys copy 
repetidamente até que todas as cópias estejam completas. Vamos ver, no próximo capítulo, 
que os dispositivos de disco têm uma capacidade semelhante de manipular várias transferên- 
cias com base em uma única requisição. 


ATAREFA DE RELÓGIO NO MINIX 3 


Os relógios (também chamados de temporizadores) são fundamentais para a operação de 
qualquer sistema de compartilhamento de tempo, por diversos motivos. Por exemplo, eles 
mantêm a hora do dia e impedem que um único processo monopolize a CPU. A tarefa de 
relógio do MINIX 3 tem certa semelhança com um driver de dispositivo, pois ela é orientada 
por interrupções geradas por um dispositivo de hardware. Entretanto, o relógio não é nem um 
dispositivo de bloco, como um disco, nem um dispositivo de caractere, como um terminal. 
Na verdade, no MINIX 3, uma interface para o relógio não é fornecida por um arquivo no di- 
retório /dev/. Além disso, a tarefa de relógio é executada em espaço de núcleo e não pode ser 
acessada diretamente pelos processos em espaço de usuário. Ela tem acesso às funções e aos 
dados do núcleo, mas os processos em espaço de usuário só podem acessá-la por intermédio 
da tarefa de sistema. Nesta seção, veremos primeiro o hardware e o software do relógio em 
geral e, então, veremos como essas idéias são aplicadas no MINIX 3. 


Hardware de relógio 


Dois tipos de relógios são usados nos computadores e ambos são bastante diferentes dos reló- 
gios de parede e de pulso usados pelas pessoas. Os relógios mais simples são ligados na rede 
elétrica de 110 ou 220 volts e causam uma interrupção em cada ciclo de tensão, em 50 ou 60 
Hz. Eles estão basicamente extintos nos PCs modernos. 

O outro tipo de relógio é constituído de três componentes: um oscilador a cristal, um 
contador e um registrador de referência, como mostrado na Figura 2-47. Quando um pedaço 
de cristal de quartzo é cortado corretamente e montado sob tensão, pode-se fazer com que 
ele gere um sinal periódico com altíssima precisão, normalmente na faixa de 5 a 200 MHz, 
dependendo do cristal escolhido. Pelo menos um circuito desses é normalmente encontrado 
em qualquer computador, fornecendo um sinal de sincronização para os diversos circuitos 
da máquina. Esse sinal alimenta o contador para fazer uma contagem regressiva até zero. 
Quando o contador chega a zero, ele causa uma interrupção da CPU. Os computadores cuja 
velocidade de relógio anunciada é mais alta do que 200 MHz normalmente utilizam um reló- 
gio mais lento e um circuito multiplicador. 


Oscilador a cristal 


AU 


O contador é decrementado a cada pulso 


O registrador de referência é usado 
para carregar o contador 


Figura 2-47 Um relógio programável. 
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Normalmente, os relógios programáveis têm vários modos de operação. No modo es- 
tanque (one shot mode), quando o relógio é iniciado, ele copia o valor do registrador de 
referência no contador e, em seguida, decrementa o contador a cada pulso do cristal. Quando 
o contador chega a zero, ele causa uma interrupção e pára, até que seja explicitamente ini- 
ciado novamente pelo software. No modo de onda quadrada (square-wave mode), após 
chegar a zero e causar a interrupção, o registrador de referência é automaticamente copiado 
no contador e o processo inteiro é repetido indefinidamente. Essas interrupções periódicas 
são chamadas de tiques de relógio. 

A vantagem do relógio programável é que sua fregiiência de interrupção pode ser con- 
trolada por software. Se for usado um cristal de 1 MHz, então o pulso do contador será dado 
a cada microssegundo. Com registradores de 16 bits, as interrupções podem ser programadas 
para ocorrer em intervalos de 1 microssegundo a 65536 milissegundos. Normalmente, os 
chips de relógio programável contêm dois ou três relógios programáveis independentemente 
e também muitas outras opções (por exemplo, contar para cima e não para baixo, interrupções 
desativadas e muitas outras). 

Para evitar que o tempo corrente seja perdido quando a energia do computador é des- 
ligada, a maioria dos computadores tem um relógio auxiliar alimentado por, implementado 
com circuitos de baixa energia como os utilizados nos relógios de pulso digitais. O relógio da 
bateria pode ser lido na inicialização. Se ele não estiver presente, o software poderá solicitar 
a data e a hora correntes para o usuário. Também existe um protocolo padrão para um sistema 
interligado em rede obter o tempo atual a partir de um computador remoto. Em qualquer caso, 
o tempo é então transformado no número de segundos desde 0:00 UTC (Universal Coordi- 
nated Time) (anteriormente conhecido como Greenwich Mean Time), do dia 1º de janeiro de 
1970, como fazem o UNIX e o MINIX 3, ou senão, de alguma outra referência. Os tiques de 
relógio são contados pelo sistema em execução e sempre que um segundo inteiro tiver decor- 
rido, o tempo real é incrementado por um. O MINIX 3 (e a maioria dos sistemas UNIX) não 
leva em conta os segundos quebrados, dos quais houve 23 desde 1970. Isso não é considerado 
uma falha importante. Normalmente, programas utilitários são fornecidos para configurar 
manualmente o relógio do sistema, o relógio auxiliar a bateria e para sincronizá-los. 

Devemos mencionar aqui que todos os computadores compatíveis com os da IBM, me- 
nos os mais antigos, têm um circuito de relógio separado que fornece sinais de temporização 
para a CPU, para os barramentos de dados internos e para outros componentes. Esse é o 
relógio a que as pessoas se referem quando falam de velocidades do relógio da CPU, medida 
em Megahertz (MHz) nos primeiros computadores pessoais e em Gigahertz (GHz) nos siste- 
mas modernos. Os circuitos básicos dos cristais de quartzo, osciladores e contadores são os 
mesmos, mas os requisitos são tão diferentes que os computadores modernos têm relógios 
independentes para controle da CPU e para temporização. 


Software de relógio 
A única coisa que o hardware de relógio faz é gerar interrupções em intervalos bem determi- 
nados. Todo o resto que envolve o tempo deve ser feito pelo software, pelo driver de relógio. 
As tarefas exatas do driver de relógio variam entre os sistemas operacionais, mas normalmen- 
te incluem a maior parte das seguintes: 

1. Manter a hora do dia. 

2. Impedir que os processos sejam executados por mais tempo do que podem. 
3. Contabilizar a utilização da CPU. 
4 


. Tratar da chamada de sistema alarm feita por processos de usuário. 
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5. Fornecer temporizadores cão de guarda (watchdog) para partes do próprio siste- 
ma. 


6. Gerar perfis de utilização, monitorar e reunir estatísticas. 


A primeira função do relógio, manter a hora do dia (também chamada de tempo real) 
não é difícil. Ela exige apenas incrementar um contador a cada tique de relógio, conforme 
mencionado anteriormente. A única coisa a observar é o número de bits no contador de hora 
do dia. Com uma velocidade de relógio de 60 Hz, um contador de 32 bits estourará em apenas 
pouco mais de 2 anos. Claramente, o sistema não pode armazenar em 32 bits o tempo real 
como o número de tiques desde 1º de janeiro de 1970. 

Três estratégias podem ser adotadas para resolver esse problema. A primeira é utilizar 
um contador de 64 bits, embora isso torne a manutenção do contador mais dispendiosa, pois 
ela precisa ser feita muitas vezes por segundo. A segunda é manter a hora do dia em segun- 
dos, em vez de tiques, usando um contador auxiliar para contar os tiques até que um segundo 
inteiro tenha sido acumulado. Como 2” segundos correspondem a mais do que 136 anos, este 
método funcionará até o século XXII. 

A terceira estratégia é contar os tiques, mas fazer isso com relação à hora em que o sis- 
tema foi inicializado, em vez de fazer em relação a um momento externo fixo. Quando o reló- 
gio auxiliar a bateria é lido ou quando o usuário informa o tempo real, a hora da inicialização 
do sistema é calculada a partir do valor da hora do dia corrente e armazenada em memória de 
uma forma conveniente. Quando a hora do dia é solicitada, a hora armazenada é somada ao 
contador para se obter a hora do dia atual. As três estratégias aparecem na Figura 2-48. 


H 64 bits =| |[--—s2bits — H— 32 bits — 
Hora do dia Número de tiques 


em segundos no segundo corrente 


Hora da inicialização do 
sistema em segundos 


(a) (b) (c) 


Figura 2-48 Três maneiras de manter a hora do dia. 


A segunda função do relógio é impedir que os processos sejam executados por tempo 
demais. Quando um processo é iniciado, o escalonador deve inicializar um contador com o 
valor do quantum desse processo em tiques de relógio. Em cada interrupção de relógio, o 
driver decrementa o contador de quantum por 1. Quando ele chega a zero, o driver chama o 
escalonador para selecionar um outro processo para executar. 

A terceira função do relógio é fazer a contabilizar o tempo de uso CPU. A maneira de 
fazer isso de forma mais precisa é iniciar um segundo temporizador, diferente do temporiza- 
dor principal do sistema, quando um processo é iniciado. Quando esse processo for interrom- 
pido, o temporizador pode ser lido para informar por quanto tempo o processo foi executado. 
Para fazer as coisas direito, o segundo temporizador deve ser salvo na ocorrência de uma 
interrupção e restaurado depois. 

Uma maneira menos precisa, mas muito mais simples, é manter em uma variável glo- 
bal, um ponteiro para a entrada da tabela de processos do processo que está correntemente 
em execução. A cada tique de relógio, um campo é incrementado na entrada do processo 
corrente. Desse modo, cada tique de relógio é “cobrado” do processo que está em execução 
no momento do tique. Um problema secundário dessa estratégia é que, se ocorrerem muitas 


204 


SISTEMAS OPERACIONAIS 


interrupções durante a execução de um processo, ele ainda será cobrado por um tique inteiro, 
mesmo que não tenha realizado muito trabalho. A contabilidade correta da CPU durante as 
interrupções é dispendiosa demais e raramente é feita. 

No MINIX 3, e em muitos outros sistemas, um processo pode solicitar que o sistema 
operacional o avise após certo intervalo de tempo. Normalmente, o aviso é um sinal, uma 
interrupção, uma mensagem ou algo semelhante. Uma aplicação que exige tais avisos é a que 
envolve comunicação em rede, na qual um pacote não reconhecido dentro de certo intervalo 
de tempo deve ser retransmitido. Outra aplicação é a instrução auxiliada por computador 
(computer aided instruction), onde um aluno que não responde dentro de certo tempo recebe 
a resposta. 

Se o driver de relógio tivesse hardware suficiente, ele poderia configurar um relógio 
separado para cada pedido. Não sendo esse o caso, ele precisa simular vários relógios virtuais 
a partir de um único relógio físico. Uma maneira é ter uma tabela na qual é mantido o tempo 
de sinal de todos os temporizadores pendentes, assim como uma variável fornecendo o tempo 
do próximo sinal. Quando a hora do dia é atualizada, o driver verifica se o sinal mais próximo 
ocorreu. Se tiver ocorrido, a tabela é pesquisada para buscar o próximo a ocorrer. 

Ao se esperar muitos sinais, é mais eficiente simular vários relógios enfileirando todos 
os pedidos pendentes, ordenados no tempo, em uma lista encadeada, como mostrado na Fi- 
gura 2-49. Cada entrada da lista informa quantos tiques de relógio após o anterior deve-se 
esperar antes de causar um sinal. Neste exemplo, estão pendentes sinais para 4203, 4207, 
4213, 4215 e 4216. 

Na Figura 2-49, um temporizador acabou de expirar. A próxima interrupção ocorrerá 
em 3 tiques e 3 acabaram de ser carregados. Em cada tique, Próximo sinal é decrementado. 
Quando chegar a 0, acontecerá o sinal correspondente ao primeiro item da lista e esse item 
será removido da lista. Então, Próximo sinal será configurado com valor da entrada que agora 
está no início da lista, neste exemplo, 4. Em muitos casos, usar tempos absolutos, em vez de 
tempos relativos é mais conveniente e essa é a estratégia utilizada pelo MINIX 3. 


Primeiro da lista 
(nó cabeça) 


eee 


Figura 2-49 Simulando vários temporizadores com um único relógio. 


Hora atual Próximo sinal 


Note que, durante uma interrupção de relógio, o driver tem várias coisas a fazer. Essas 
coisas incluem incrementar o tempo real, decrementar o quantum e verificar se é 0, contabili- 
zar o uso de CPU e decrementar o contador de alarme. Entretanto, cada uma dessas operações 
foi cuidadosamente planejada para ser muito rápida, pois elas precisam ser repetidas muitas 
vezes por segundo. 

Partes do sistema operacional também precisam configurar temporizadores. Eles são 
chamados de temporizadores de cão de guarda (watchdogs). Quando estudarmos o driver 
de disco rígido, veremos que uma chamada para despertar é programada sempre que é envia- 
do um comando para a controladora de disco; portanto, uma tentativa de recuperação pode 
ser feita se o comando falhar completamente. Os drivers de disquete usam temporizadores 
para esperar que o motor do disco ganhe velocidade e para desligá-lo, caso nenhuma ativida- 
de ocorra por algum tempo. Algumas impressoras com cabeçote de impressão móvel podem 
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imprimir a 120 caracteres/seg (8,3 ms/caractere), mas não conseguem retornar o cabeçote de 
impressão para a margem esquerda em 8,3 ms; portanto, o driver de terminal deve responder 
mais lentamente, após a digitação de enter. 

O mecanismo usado pelo driver de relógio para tratar de temporizadores de cão de 
guarda é o mesmo dos sinais de usuário. A única diferença é que, quando um temporizador 
expira, em vez de causar um sinal, o driver de relógio chama uma função fornecida pelo pro- 
cesso que fez a chamada. A função faz parte do código desse processo. Isso apresentou um 
problema no projeto do MINIX 3, pois um dos objetivos era remover os drivers do espaço 
de endereçamento do núcleo. A resposta rápida é que a tarefa de sistema, que está no espaço 
de núcleo, pode configurar alarmes em nome de alguns processos do espaço de usuário e, 
então, notificá-los quando um temporizador expirar. Vamos examinar melhor esse mecanis- 
mo mais adiante. 

O último item em nossa lista é o traçado de perfil (profiling). Alguns sistemas operacio- 
nais fornecem um mecanismo por meio do qual um programa de usuário pode fazer o sistema 
construir um histograma de seu contador de programa, para que possa ver onde está gastando 
seu tempo. Quando traçar o perfil é uma possibilidade, a cada tique o driver verifica o inter- 
valo de endereços acessado e registra o número de vezes que esse intervalo foi referenciado 
com o auxílio de um contador. Esse mecanismo também pode ser usado para traçar o perfil 
do sistema em si. 


Visão geral do driver de relógio no MINIX 3 


O driver de relógio do MINIX 3 está contido no arquivo kernel/clock.c. Ele pode ser conside- 
rado como tendo três partes funcionais. Primeiramente, assim como os drivers de dispositivo 
que veremos no próximo capítulo, existe um mecanismo de tarefa que é executado em um 
laço, onde fica esperando por mensagens e enviando para sub-rotinas que executam a ação 
solicitada em cada mensagem. Entretanto, essa estrutura é quase rudimentar na tarefa de 
relógio. O mecanismo de mensagem é dispendioso, exigindo toda a sobrecarga de uma troca 
de contexto. Portanto, para o relógio, isso só é usado quando há um volume substancial de 
trabalho a ser feito. Apenas um tipo de mensagem é recebido, há apenas uma sub-rotina para 
atender a mensagem e não é enviada uma mensagem de resposta quando a tarefa está pronta. 

A segunda parte principal do software de relógio é a rotina de tratamento de interrupção 
ativada 60 vezes a cada segundo. Ela realiza a temporização básica, atualizando uma variável 
que conta os tiques de relógio desde que o sistema foi inicializado. Ela compara isso com o 
tempo de expiração do próximo temporizador. Ela também atualiza contadores que registram 
quanto foi usado do quantum do processo corrente e o tempo total utilizado por esse proces- 
so. Se a rotina de tratamento de interrupção detecta que um processo utilizou seu quantum ou 
que um temporizador expirou, ela gera a mensagem que vai para o laço de tarefa principal. 
Caso contrário, nenhuma mensagem é enviada. A estratégia aqui é que, para cada tique de 
relógio, a rotina de tratamento realiza o mínimo necessário, o mais rápido possível. A tarefa 
principal é ativada somente quando existe trabalho substancial a fazer. 

A terceira parte geral do software de relógio é um conjunto de sub-rotinas que fornecem 
suporte genérico, mas que não são chamadas em resposta às interrupções de relógio, ou pela 
rotina de tratamento de interrupção ou pelo laço de tarefa principal. Uma dessas sub-rotinas 
é codificada como PRIVATE e é chamada antes da entrada no laço de tarefa principal. Ela 
inicializa o relógio, o que exige configurar o chip de relógio para fazer com que ele gere inter- 
rupções nos intervalos desejados. A rotina de inicialização também armazena o endereço da 
rotina de tratamento de interrupção no local apropriado para ser executada quando o chip de 
relógio provoca uma IRQ 8 controlador de interrupção. 
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O restante das sub-rotinas em clock.c é declarada como PUBLIC e pode ser chamada a 
partir de qualquer parte no binário do núcleo. Na verdade, nenhuma delas é chamada a partir 
de clock.c em si. Elas são chamadas principalmente pela tarefa de sistema, para atender as 
chamadas de sistema relacionadas com o tempo. Essas sub-rotinas fazem coisas como ler o 
contador do tempo desde a inicialização, sincronizar com a resolução do tique de relógio, ou 
ler um registrador no próprio chip de relógio para sincronizações que exigem resolução em 
microssegundos. Outras sub-rotinas são usadas para configurar e reconfigurar temporizado- 
res. Finalmente, é fornecida uma sub-rotina para ser chamada quando o MINIX 3 for des- 
ligado. Ela reconfigura os parâmetros do temporizador de hardware com aqueles esperados 
pela BIOS. 


A tarefa de relógio 


O laço principal da tarefa de relógio aceita apenas um tipo de mensagem, HARD INT, pro- 
veniente da rotina de tratamento de interrupção. Tudo mais é erro. Além disso, ela não rece- 
be essa mensagem para cada interrupção de tique de relógio, embora a sub-rotina chamada 
sempre que uma mensagem é recebida se chame do clocktick. Uma mensagem é recebida 
e do clocktick é chamada somente se o escalonamento de processo for necessário ou se um 
temporizador tiver expirado. 


A rotina de tratamento de interrupção de relógio 


A rotina de tratamento de interrupção é executada sempre que o contador no chip de relógio 
chega a zero e gera uma interrupção. É aí que é feito o trabalho básico de temporização. No 
MINIX 3, o tempo é mantido usando-se o método da Figura 2-48(c). Entretanto, em clock.c, 
é mantido apenas o contador de tiques desde a inicialização; os registros do momento da ini- 
cialização são mantidos em outro lugar. O software de relógio fornece apenas a contagem de 
tiques corrente para ajudar uma chamada de sistema para o tempo real. Mais processamento é 
feito por um dos servidores. Isso está de acordo com a estratégia do MINIX 3 de mover fun- 
cionalidade para processos que são executados em espaço de usuário. 

Na rotina de tratamento de interrupção, o contador local é atualizado para cada inter- 
rupção recebida. Quando as interrupções são desativadas, os tiques são perdidos. Em alguns 
casos, é possível corrigir esse efeito. Está disponível uma variável global para contar tiques 
perdidos e ela é adicionada ao contador principal e, então, reconfigurada com o valor zero 
sempre que a rotina de tratamento é ativada. Veremos um exemplo de como isso é usado, na 
seção de implementação. 

A rotina de tratamento também afeta variáveis na tabela de processos, para propósitos de 
cobrança e controle de processo. Uma mensagem é enviada para a tarefa de relógio somente 
se o tempo corrente tiver ultrapassado o tempo de expiração do próximo temporizador agen- 
dado ou se o quantum do processo que está em execução tiver sido decrementado até zero. 
Tudo que é feito no serviço de interrupção é uma operação de inteiros simples — aritmética, 
comparação, E/OU lógico ou atribuição — que um compilador C pode transformar facilmen- 
te em operações de máquina primitivas. No pior caso, existe cinco somas ou subtrações e seis 
comparações, além de algumas operações lógicas e atribuições para completar o serviço de 
interrupção. Em particular, não há nenhuma sobrecarga de chamada de sub-rotina. 


Temporizadores de cão de guarda 


Anteriormente, deixamos pendente a questão de como podem ser fornecidos temporizadores 
de cão de guarda para os processos em espaço de usuário, que normalmente são considerados 
como funções fornecidas pelo usuário, que fazem parte do código do usuário e são executadas 
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quando um temporizador expira. Claramente, isso não pode ser feito no MINIX 3. Mas pode- 
mos usar um alarme síncrono para ligar o núcleo ao espaço de usuário. 

Este é um bom momento para explicarmos o que significa um alarme síncrono. Pode 
chegar um sinal ou um cão de guarda convencional pode ser ativado, sem qualquer relação 
com a parte de um processo que esteja correntemente em execução; portanto, esses mecanis- 
mos são assíncronos. Um alarme síncrono é emitido como uma mensagem e, assim, pode 
ser recebido apenas quando o destinatário tiver executado a instrução receive. Então, dizemos 
que ele é síncrono, pois só será recebido quando o destinatário esperar por ele. Se o método 
notify for usado para informar a um destinatário sobre um alarme, o remetente não precisará 
ser bloqueado e o destinatário não precisará se preocupar com a perda do alarme. As mensa- 
gens de notify são salvas, caso o destinatário não esteja esperando. É usado um mapa de bits, 
com cada bit representando uma possível fonte de notificação. 

Os temporizadores de cão de guarda tiram proveito do campo s alarm timer de tipo 
timer t existente em cada elemento da tabela priv. Cada processo de sistema tem uma entrada 
na tabela priv. Para configurar um temporizador, um processo de sistema em espaço de usuá- 
rio faz uma chamada de sys setalarm, a qual é manipulada pela tarefa de sistema. A tarefa 
de sistema é compilada em espaço de núcleo e, assim, pode inicializar um temporizador em 
nome do processo que fez a chamada. A inicialização envolve colocar em um determinado 
campo o endereço de uma função a ser executada quando o temporizador expirar e, então, 
inserir o temporizador em uma lista de temporizadores, como se vê na Figura 2-49. 

A função a ser executada também precisa estar em espaço de núcleo, é claro. Sem 
problemas. A tarefa de sistema contém uma função de cão de guarda, cause alarm, que gera 
uma mensagem notify ao expirar, causando um alarme síncrono para o usuário. Esse alarme 
pode ativar a função de cão de guarda em espaço de usuário. Dentro do binário do núcleo, 
esse é um verdadeiro cão de guarda, mas para o processo que solicitou o temporizador, trata- 
se de um alarme síncrono. Isso não é o mesmo que fazer o temporizador executar uma função 
no espaço de endereçamento do destino. Há um pouco mais de sobrecarga, mas é mais sim- 
ples do que uma interrupção. 

O que escrevemos acima foi qualificado: dissemos que a tarefa de sistema pode confi- 
gurar alarmes em nome de alguns processos em espaço de usuário. O mecanismo que acaba- 
mos de descrever só funciona para processos de sistema. Cada processo de sistema tem uma 
cópia da estrutura priv, mas uma única cópia é compartilhada por todos os processos que não 
são de sistema (de usuário). As partes da tabela priv que não podem ser compartilhadas, como 
o mapa de bits das notificações pendentes e o temporizador, não podem ser utilizadas pelos 
processos de usuário. A solução é esta: o gerenciador de processos gerencia os temporiza- 
dores em nome dos processos de usuário de maneira semelhante a como a tarefa de sistema 
gerencia temporizadores para processos de sistema. Todo processo tem seu próprio campo 
timer. t na parte referente ao gerenciador de processos da tabela de processos. 

Quando um processo de usuário faz uma chamada de sistema alarm para solicitar a 
configuração de um alarme, ela é manipulada pelo gerenciador de processos, o qual configura 
o temporizador e o insere em sua lista de temporizadores. O gerenciador de processos pede 
para a tarefa de sistema para que envie a ele uma notificação quando o primeiro temporiza- 
dor na lista de temporizadores estiver programado para expirar. O gerenciador de processos 
só precisa pedir ajuda quando o início de seu encadeamento de temporizadores mudar, ou 
porque o primeiro temporizador expirou ou foi cancelado, ou porque foi recebido um novo 
pedido que deve entrar no encadeamento antes do atual primeiro. Isso é usado para suportar a 
chamada de sistema alarm do padrão POSIX. A função a ser executada está dentro do espaço 
de endereçamento do gerenciador de processos. Quando ela é executada, é enviado um sinal 
para o processo de usuário que solicitou o alarme, em vez de uma notificação. 
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Resolução de milissegundos 


Em clock.c existe uma função que fornece uma base de tempo com resolução de microsse- 
gundos. Atrasos de poucos microssegundos podem ser necessários para diversos dispositivos 
de E/S. Não existe nenhuma maneira prática de fazer isso usando alarmes e a interface de 
passagem de mensagens. O contador utilizado para gerar as interrupções de relógio pode ser 
lido diretamente. Ele é decrementado aproximadamente a cada 0,8 microssegundos e chega 
a zero 60 vezes por segundo (ou a cada 16,67 milissegundos). Para ser útil na temporização 
de E/S, ele teria de ser consultado sequencialmente por uma função em execução em espaço 
de núcleo, mas muito trabalho foi feito para retirar os drivers desse espaço. Atualmente, essa 
função é usada apenas como uma fonte de variação para o gerador de números aleatórios. Em 
um sistema muito rápido, ela poderia ter mais utilidade, mas isso é um projeto futuro. 


Resumo dos serviços de relógio 


A Figura 2-50 resume os diversos serviços fornecidos direta ou indiretamente por clock.c. 
Existem várias funções declaradas como PUBLIC que podem ser chamadas a partir do núcleo 
ou da tarefa de sistema. Todos os outros serviços estão disponíveis apenas indiretamente, 
por meio de chamadas de sistema manipuladas, em última análise, pela tarefa de sistema. 
Outros processos de sistema podem chamar a tarefa de sistema diretamente, mas os pro- 
cessos de usuário devem chamar o gerenciador de processos, o qual também conta com a 
tarefa de sistema. 


Serviço Acesso Resposta Clientes 

get uptime Chamada de função | Tiques Núcleo ou tarefa de sistema 

set timer Chamada de função | Nenhuma | Núcleo ou tarefa de sistema 

reset timer Chamada de função | Nenhuma | Núcleo ou tarefa de sistema 

read clock Chamada de função | Contagem | Núcleo ou tarefa de sistema 

clock stop Chamada de função | Nenhuma | Núcleo ou tarefa de sistema 

Alarme síncrono Chamada de sistema | Notificação | Servidor ou driver, via tarefa de 
sistema 

Alarme do POSIX | Chamada de sistema | Sinal Processo de usuário, via 
gerenciador de processos 

Tempo Chamada de sistema | Mensagem | Qualquer processo, via 
gerenciador de processos 


Figura 2-50 Os serviços relacionados ao tempo suportados pelo driver de relógio. 


O núcleo ou a tarefa de sistema pode obter o tempo de funcionamento corrente, ou 
configurar ou reconfigurar um temporizador sem a sobrecarga de uma mensagem. O núcleo 
ou a tarefa de sistema também pode chamar read clock, que lê o contador no chip tempori- 
zador, para obter o tempo em unidades de aproximadamente 0,8 microssegundos. A função 
clock stop se destina a ser chamada apenas quando o MINIX 3 for desligado. Ela restaura a 
velocidade de relógio da BIOS. Um processo de sistema (um driver ou um servidor) pode so- 
licitar um alarme síncrono, o que causa a ativação de uma função de cão de guarda em espaço 
de núcleo e uma notificação para o processo solicitante. Um alarme do POSIX é solicitado 
por um processo de usuário chamando o gerenciador de processos, o qual pede então para que 
a tarefa de sistema ative um cão de guarda. Quando o temporizador expira, a tarefa de sistema 
notifica o gerenciador de processos e este envia um sinal para o processo de usuário. 
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2.8.4 Implementação do driver de relógio no MINIX 3 


A tarefa de relógio não utiliza nenhuma estrutura de dados importante, mas diversas variáveis 
são usadas para monitorar o tempo. A variável realtime (linha 10462) é básica — ela conta 
todos os tiques de relógio. Uma variável global, lost ticks, é definida em glo.h (linha 5333). 
Essa variável é fornecida para uso em qualquer função executada em espaço de núcleo que 
possa desativar interrupções por um tempo longo o suficiente para que um ou mais tiques 
de relógio pudessem ser perdidos. Atualmente, ela é usada pela função int86 em klib386.s. 
Int86 usa o monitor de inicialização para gerenciar a transferência de controle para a BIOS e 
o monitor retorna o número de tiques de relógio contados enquanto a chamada da BIOS esta- 
va ocupada no registrador ecx, imediatamente antes do retorno para o núcleo. Isso funciona 
porque, embora o chip de relógio não esteja ativando a rotina de interrupção de relógio do 
MINIX 3 quando o pedido da BIOS é manipulado, o monitor de inicialização pode verificar 
o tempo com a ajuda da BIOS. 

O driver de relógio acessa diversas outras variáveis globais. Ele usa proc ptr, prev ptre 
bill ptr para referenciar a entrada da tabela de processos do processo que está correntemente 
em execução, do processo que foi executado anteriormente e do processo que é cobrado pelo 
tempo. Dentro dessas entradas da tabela de processos, ele acessa vários campos, incluindo 
p-user timeep sys time para contabilização, e p ticks left para fazer a contagem regressiva 
do quantum de um processo. 

Quando o MINIX 3 inicia, todos os drivers são chamados. A maioria deles realiza al- 
guma inicialização e, então, tenta obter uma mensagem e é bloqueada. O driver de relógio, 
clock task (linha 10468), também faz isso. Primeiro, ele chama init clock para inicializar a 
frequência do relógio programável com 60 Hz. Quando uma mensagem é recebida, ele chama 
do clocktick, caso a mensagem tenha sido HARD INT (linha 10486). Qualquer outro tipo de 
mensagem inesperado e é tratado como um erro. 

Do clocktick (linha 10497) não é chamada em cada tique do relógio; portanto, seu 
nome não é uma descrição exata de sua função. Ela é chamada quando a rotina de tratamento 
de interrupção determinou que pode haver algo importante a fazer. Uma das condições que 
resultam na execução de do clocktick é o processo corrente usando todo o seu quantum. Se 
puder haver preempção do processo (nas tarefas de sistema e de relógio não pode haver), uma 
chamada para lock dequeue, seguida imediatamente por uma chamada para lock enqueue 
(linhas 10510 a 10512), retira o processo de sua fila e, em seguida, o torna pronto novamente 
e reprograma sua execução. A outra coisa que ativa do clocktick é a expiração de um tempo- 
rizador de cão de guarda. Os temporizadores e as listas encadeadas de temporizadores são tão 
utilizados no MINIX 3, que foi criada uma biblioteca de funções para suportá-los. A função 
de biblioteca tmrs exptimers, chamada na linha 10517, executa as funções de cão de guarda 
para todos os temporizadores expirados e os desativa. 

Init clock (linha 10529) é chamada apenas uma vez, quando a tarefa de relógio é inicia- 
da. Existem vários lugares para onde alguém poderia apontar e dizer, “É aqui que o MINIX 3 
começa a executar”. Este é um candidato; o relógio é fundamental para um sistema multitare- 
fa preemptivo. Init clock escreve três bytes no chip de relógio, que configuram seu modo e a 
contagem correta no registrador mestre. Então, ela registra seu número de processo, a IRQ e 
o endereço da rotina de tratamento para que as interrupções sejam direcionadas corretamente. 
Finalmente, ela ativa o chip controlador de interrupção para aceitar interrupções de relógio. 

A função seguinte, clock stop, desfaz a inicialização do chip de relógio. Ela é decla- 
rada como PUBLIC e não é chamada a partir de qualquer lugar em clock.c. Essa função foi 
colocada aqui devido à semelhança óbvia com init clock. Ela só é chamada pela tarefa de 
sistema quando o MINIX 3 é desligado e o controle deve ser retornado para o monitor de 
inicialização. 
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2.9 


Assim que init clock é executada (ou, mais precisamente, 16,67 milissegundos depois), 
ocorre a primeira interrupção de relógio e elas se repetem 60 vezes por segundo, enquanto 
o MINIX 3 está sendo executado. O código em clock handler (linha 10556) provavelmente 
é executado com mais fregiiência do que qualquer outra parte do sistema MINIX 3. Conse- 
quentemente, clock handler foi construída de forma a ser rápida. As únicas chamadas de sub- 
rotina estão na linha 10586; elas só são necessárias se estiverem em execução em um sistema 
IBM PS/2 obsoleto. A atualização do tempo corrente (em tiques) é feita nas linhas 10589 a 
10591. Então, os tempos do usuário e da contabilização são atualizados. 

Foram tomadas decisões no projeto da rotina de tratamento que poderiam ser questio- 
nadas. São feitos dois testes na linha 10610 e, se uma das condições for verdadeira, a tarefa 
de relógio será notificada. A função do clocktick, chamada pela tarefa de relógio, repete os 
dois testes para decidir o que precisa ser feito. Isso é necessário porque a chamada de notify 
usada pela rotina de tratamento não pode passar nenhuma informação para distinguir condi- 
ções diferentes. Deixamos para o leitor considerar as alternativas e como elas poderiam ser 
avaliadas. 

O restante de clock.c contém funções utilitárias que já mencionamos. Get uptime (linha 
10620) apenas retorna o valor de realtime, que é visível apenas para as funções em clock.c. 
Set timer e reset timer usam outras funções da biblioteca de temporizador que cuidam dos 
detalhes da manipulação de um encadeamento de temporizadores. Finalmente, read clock lê 
e retorna o valor corrente no registrador de contagem regressiva do chip de relógio. 


RESUMO 


Para ocultar os efeitos das interrupções, os sistemas operacionais oferecem um modelo con- 
ceitual composto de processos sequenciais executando em paralelo. Os processos podem se 
comunicar usando primitivas de comunicação entre processos, como semáforos, monitores 
ou mensagens. Essas primitivas são usadas para garantir que dois processos jamais estejam 
em suas seções críticas ao mesmo tempo. Um processo pode estar em execução, estar apto a 
executar (pronto) ou estar bloqueado, e pode mudar de estado quando ele ou outro processo 
executar uma das primitivas de comunicação entre processos. 

As primitivas de comunicação entre processos podem ser utilizadas para resolver pro- 
blemas como o do produtor-consumidor, da janta dos filósofos e do leitor-escritor. Mesmo 
com essas primitivas, é preciso tomar cuidado para evitar erros e impasses. Muitos algoritmos 
de escalonamento são conhecidos, incluindo round-robin, escalonamento por prioridade, filas 
multinível e escalonadores baseados em política. 

O MINIX 3 suporta o conceito de processo e fornece mensagens para comunicação 
entre processos. As mensagens não são colocadas em buffers; portanto, uma operação send 
só é bem-sucedida quando o destinatário está esperando por ela. Analogamente, uma ope- 
ração receive só é bem-sucedida quando uma mensagem já está disponível. Se uma dessas 
operações não for bem-sucedida, o processo que fez a chamada será bloqueado. O MINIX 
3 também fornece suporte para mensagens não-bloqueantes com uma primitiva notify. Uma 
tentativa de enviar notify para um destinatário que não está esperando resulta na ativação de 
um bit, o que dispara uma notificação quando uma operação receive é feita posteriormente. 

Como exemplo do fluxo de mensagens, considere um usuário executando uma operação 
read. O processo do usuário envia uma mensagem para o sistema de arquivos fazendo uma 
requisição. Se os dados não estiverem na cache do sistema de arquivos, este pedirá ao driver 
para que os leia do disco. Então, o sistema de arquivos é bloqueado e fica esperando os dados. 
Quando a interrupção de disco ocorrer, a tarefa de sistema é notificada, permitindo sua res- 
posta para o driver de disco, o qual então responde para o sistema de arquivos. Neste ponto, 
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o sistema de arquivos pede para que a tarefa de sistema copie os dados de sua cache, onde foi 
armazenado o bloco recentemente solicitado, para o usuário. Essas etapas estão ilustradas na 
Figura 2-46. 

Após uma interrupção, pode haver uma troca de processo. Quando um processo é inter- 
rompido, é criada uma pilha dentro da entrada da tabela de processos desse processo e todas 
as informações necessárias para reiniciá-lo são colocadas nesta nova pilha. Qualquer proces- 
so pode ser reiniciado configurando-se o ponteiro de pilha para apontar para sua entrada na 
tabela de processos e iniciando-se uma sequência de instruções para restaurar os registradores 
da CPU, culminando com uma instrução iretd. O escalonador decide qual entrada da tabela de 
processos vai colocar no ponteiro de pilha. 

As interrupções não podem ocorrer quando o núcleo em si está em execução. Se ocorrer 
uma exceção quando o núcleo estiver em execução, a pilha do núcleo (e não uma pilha dentro 
da tabela de processos) será usada. Quando uma interrupção tiver sido atendida, um processo 
será reiniciado. 

O algoritmo de escalonamento do MINIX 3 usa múltiplas filas de prioridade. Normal- 
mente, os processos de sistema são executados nas filas de prioridade mais alta e os processos 
de usuário nas filas de prioridade mais baixa, mas as prioridades são atribuídas de acordo com 
o processo. Um processo preso em um laço pode ter sua prioridade reduzida temporariamen- 
te; a prioridade pode ser restaurada, quando outros processos tiverem tido uma chance de 
executar. O comando nice pode ser usado para mudar a prioridade de um processo dentro de 
limites definidos. Os processos são executados em um sistema de rodízio (round-robin), por 
um quantum que pode variar de acordo com o processo. Entretanto, depois que um processo 
tiver sido bloqueado e se tornar pronto novamente, ele será colocado no início de sua fila, 
com apenas a parte não utilizada de seu quantum. Isso se destina a proporcionar uma resposta 
mais rápida para os processos que estão fazendo E/S. Os drivers de dispositivo e os servi- 
dores podem ter um quantum grande, pois espera-se que eles sejam executados até serem 
bloqueados. Entretanto, mesmo os processos de sistema podem ser preemptados, caso sejam 
executados por um tempo longo demais. 

A imagem do núcleo inclui uma tarefa de sistema que facilita a comunicação de pro- 
cessos em espaço de usuário com o núcleo. Ela suporta os servidores e drivers de dispositivo 
executando operações privilegiadas em seus nomes. No MINIX 3, a tarefa de relógio também 
é compilada com o núcleo. Ela não é um driver de dispositivo no sentido comum. Os proces- 
sos em espaço de usuário não podem acessar o relógio como um dispositivo. 


PROBLEMAS 


1. Por que a multiprogramação é fundamental para a operação de um sistema operacional moderno? 


2. Quais são os três estados principais em que um processo pode estar? Descreva sucintamente o 
significado de cada um. 


3. Suponha que você fosse projetar uma arquitetura de computador avançada que fizesse a troca de 
processo em hardware, em vez de ter interrupções. De quais informações a CPU precisaria? Des- 
creva como a troca de processo em hardware poderia funcionar. 


4. Em todos os computadores atuais, pelos menos parte das rotinas de tratamento de interrupção é 
escrita em linguagem assembly. Por quê? 


5. Redesenhe a Figura 2-2, adicionando dois novos estados: Novo e Terminado. Quando um processo 
é criado, ele está inicialmente no estado Novo. Quando ele sai, está no estado Terminado. 
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No texto, foi dito que o modelo da Figura 2-6(a) não era conveniente para um servidor de arquivos 
usando uma cache na memória. Por que não? Cada processo poderia ter sua própria cache? 


Qual é a diferença fundamental entre um processo e uma thread? 


Em um sistema com threads, existe normalmente uma pilha por thread ou uma pilha por processo? 
Explique. 


O que é uma condição de corrida? 


Dê um exemplo de condição de corrida que poderia ocorrer na compra de passagens aéreas por 
duas pessoas que querem viajar juntas. 


Escreva um script em shell que produza um arquivo de números segienciais lendo o último número 
no arquivo, somando 1 a ele e depois anexando no arquivo. Execute uma instância do script em ba- 
ckground e uma foreground, cada uma acessando o mesmo arquivo. Quanto tempo demorará para 
que uma condição de corrida se manifeste? O que é seção crítica? Modifique o script para evitar a 
condição de corrida (Dica: use 


In file file.lock 
para controlar o acesso ao arquivo de dados.) 


Uma instrução como 


In file file.lock 


é um mecanismo de bloqueio eficiente para um programa de usuário como os scripts usados no 
problema anterior? Por que sim (ou por que não)? 


A solução de espera ocupada usando a variável turn (Figura 2-10) funciona quando os dois proces- 
sos estão sendo executados em um multiprocessador de memória compartilhada; isto é, duas CPUs 
compartilhando uma memória comum? 


Considere um computador que não possua uma instrução TEST AND SET LOCK, mas que tenha 
uma instrução para trocar o conteúdo de um registrador e de uma palavra de memória em uma 
única ação indivisível. Isso pode ser usado para escrever uma rotina enter. region, como aquela 
encontrada na Figura 2-12? 


Faça um esboço de como um sistema operacional que pode desativar interrupções poderia imple- 
mentar semáforos. 


Mostre como semáforos contadores (isto é, semáforos que podem conter um valor arbitrariamente 
grande) podem ser implementados usando-se apenas semáforos binários e instruções de máquina 
normais. 


Na Seção 2.2.4, foi descrita uma situação com um processo de alta prioridade, H, e um processo de 
baixa prioridade, L, que levava H a entrar em um laço infinito. O mesmo problema ocorrerá se for 
usado escalonamento round-robin, em vez de escalonamento por prioridade? Discuta. 


Dentro dos monitores, o sincronismo utiliza variáveis de condição e duas operações espe- 
ciais, WAIT e SIGNAL. Uma forma mais geral de sincronização seria ter uma única primitiva, 
WAITUNTIL, que tivesse como parâmetro um predicado booleano arbitrário. Assim, alguém 
poderia escrever, por exemplo, 


WAITUNTILx<Oory+z<n 


A primitiva SIGNAL não seria mais necessária. Esse esquema é claramente mais geral do que o 
de Hoare ou Brinch Hansen, mas não é utilizado. Por que não? (Dica: pense a respeito da imple- 
mentação.) 


Um restaurante fast food tem quatro tipos de funcionários: (1) os atendentes, que anotam os pedi- 
dos dos clientes; (2) os cozinheiros, que preparam o alimento; (3) os embaladores, que colocam 
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o alimento em saquinhos; e (4) os caixas, que entregam os saquinhos para os clientes e recebem 
o dinheiro. Cada funcionário pode ser considerado um processo de comunicação sequencial. Que 
forma de comunicação entre processos eles utilizam? Relacione esse modelo com os processos no 
MINIX 3. 


Suponha que temos um sistema de passagem de mensagens usando caixas de correio (mailbox). Ao 
enviar para uma caixa de correio cheia ou ao tentar receber de uma caixa vazia, um processo não 
é bloqueado. Em vez disso, ele recebe um código de erro. O processo responde ao código de erro 
apenas tentando novamente, repetidamente, até ser bem-sucedido. Esse esquema leva a condições 
de corrida? 


Na solução do problema da janta dos filósofos (Figura 2-20), por que a variável de estado é confi- 
gurada como HUNGRY na função take forks? 


Considere a função put forks da Figura 2-20. Suponha que a variável state[i] tenha sido configura- 
da como THINKING após as duas chamadas para test e não antes. Como essa alteração afetaria a 
solução para o caso de 3 filósofos? E para 100 filósofos? 


O problema dos leitores e escritores pode ser formulado de várias maneiras com relação a qual ca- 
tegoria de processos pode ser iniciada e quando. Descreva completamente três variações diferentes 
do problema, cada uma favorecendo (ou não favorecendo) alguma categoria de processos. Para cada 
variação, especifique o que acontece quando um leitor ou um escritor se torna pronto para acessar a 
base de dados e o que acontece quando um processo tiver terminado de usar a base de dados. 


Os computadores CDC 6600 podiam manipular até 10 processos de E/S simultaneamente, usando 
uma forma interessante de escalonamento round-robin, chamada compartilhamento de proces- 
sador. Uma troca de processo ocorria após cada instrução, de modo que a instrução 1 vinha do 
processo 1, a instrução 2 vinha do processo 2 etc. A troca de processo era feita por um hardware es- 
pecial e a sobrecarga era zero. Se um processo precisasse de T segundos para terminar na ausência 
de concorrência, de quanto tempo ela precisaria se fosse usado compartilhamento de processador 
com n processos? 


Normalmente, os escalonadores round-robin mantêm uma lista de todos os processos executáveis, 
com cada processo ocorrendo exatamente uma vez na lista. O que aconteceria se um processo ocor- 
resse duas vezes na lista? Você pode imaginar um motivo para permitir isso? 


Medidas de determinado sistema mostraram que o processo médio é executado por um tempo T 
antes de ser bloqueado na E/S. Uma troca de processo exige um tempo S, que é efetivamente des- 
perdiçado (sobrecarga). Para escalonamento round-robin com quantum Q, escreva uma fórmula 
para a eficiência da CPU para cada uma das opções a seguir: 


(a) Q=% 
(b) Q>T 
(c) S<Q<T 
(d) 0=5 
(e) Q quase 0 


Cinco tarefas estão esperando para serem executadas. Seus tempos de execução esperados são 9, 
6, 3, 5 e X. Em que ordem elas devem ser executadas para minimizar o tempo de resposta médio? 
(Sua resposta dependerá de X.) 


Cinco tarefas de lote, de A a E, chegam em um centro de computação quase ao mesmo tempo. 
Elas têm tempos de execução estimados de 10, 6, 2, 4 e 8 minutos. Suas prioridades (determinadas 
externamente) são 3, 5, 2, 1 e 4, respectivamente, sendo 5 a prioridade mais alta. Para cada um dos 
algoritmos de escalonamento a seguir, determine o tempo de retorno médio dos processos. Ignore 
a sobrecarga da comutação de processo. 


(a) Round-robin 
(b) Escalonamento por prioridade 
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(c) Primeiro a chegar, primeiro a ser servido (execução na ordem 10, 6, 2, 4,8) 
(d) Tarefa mais curta primeira 


Para (a), suponha que o sistema seja multiprogramado e que cada tarefa recebe sua justa fatia de 
tempo da CPU. Para (b) a (d), presuma que é executada apenas uma tarefa por vez, até terminar. 
Todas as tarefas são limitadas por processamento (CPU-bound). 


Um processo executando no CTSS precisa de 30 quanta para terminar. Quantas vezes ele sofre um 
procedimento de swap, incluindo a primeira vez (antes de ser executado)? 


O algoritmo de envelhecimento com a = 1/2 está sendo usado para prever tempos de execução. As 
quatro execuções anteriores, da mais antiga para a mais recente, foram de 40, 20, 40 e 15 ms. Qual 
é a previsão do próximo tempo? 


Na Figura 2-25, vimos como o escalonamento de três níveis funciona em um sistema de lote. Essa 
idéia poderia ser aplicada em um sistema interativo sem tarefas chegando recentemente? Como? 


Suponha que as threads da Figura 2-28(a) sejam executadas na ordem: uma de 4, uma de B, uma 
de A, uma de B etc. Quantas sequências de threads possíveis existem para as quatro primeiras vezes 
que o escalonamento é feito? 


Um sistema de tempo real não-rígido tem quatro eventos periódicos, com períodos de 50, 100, 200 
e 250 ms cada um. Suponha que os quatro eventos exijam 35, 20, 10 e x ms do tempo da CPU, 
respectivamente. Qual é o maior valor de x para o qual o sistema pode fazer escalonamento? 


Durante a execução, o MINIX 3 mantém uma variável proc ptr que aponta para a entrada da tabela 
de processos do processo corrente. Por quê? 


O MINIX 3 não coloca mensagens em buffer. Explique como essa decisão de projeto causa proble- 
mas com interrupções de relógio e teclado. 


Quando uma mensagem é enviada para um processo que está em repouso no MINIX 3, a função 
ready é chamada para colocar esse processo na fila de escalonamento correta. Essa função começa 
desativando as interrupções. Explique. 


A função mini rec do MINIX 3 contém um laço. Explique para que ele serve. 


Basicamente, o MINIX 3 utiliza o método de escalonamento da Figura 2-43, com diferentes priori- 
dades para as classes. A classe mais baixa (processos de usuário) tem escalonamento round-robin, 
mas as tarefas e os servidores sempre podem ser executados até que sejam bloqueados. É possível 
que os processos da classe mais baixa passem por inanição? Por que sim (ou por que não)? 


O MINIX 3 é conveniente para aplicativos de tempo real, como aquisição de dados? Se não for, o 
que poderia ser feito para torná-lo conveniente? 


Suponha que você tenha um sistema operacional que fornece semáforos. Implemente um sistema 
de mensagens. Escreva as funções para enviar e receber mensagens. 


Um aluno de especialização em antropologia, cuja cadeira secundária é ciência da computação, en- 
volveu-se em um projeto de pesquisa para ver se os babuínos africanos podem aprender sobre im- 
passes. Ele encontra um desfiladeiro profundo e estende uma corda sobre ele, para que os babuínos 
possam cruzá-lo. Vários babuínos podem passar ao mesmo tempo, desde que todos estejam indo na 
mesma direção. Se os babuínos vindos do leste e vindos do oeste utilizarem a corda ao mesmo tem- 
po, haverá um impasse (o babuínos ficarão parados no meio), pois é impossível um passar por cima 
do outro enquanto está suspenso sobre o desfiladeiro. Se um babuíno quiser cruzar o desfiladeiro, 
deverá verificar se nenhum outro está cruzando na direção oposta. Escreva um programa usando 
semáforos que evite o impasse. Não se preocupe com uma série de babuínos se movendo para leste 
detendo indefinidamente os babuínos que se movem para oeste. 


Repita o problema anterior, mas agora evite a inanição. Quando um babuíno que deseja cruzar para 
leste chega na corda e encontra babuínos cruzando para oeste, ele espera até que a corda esteja 
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vazia, mas mais nenhum babuíno que vá para oeste pode começar, até que pelo menos um babuíno 
tenha cruzado na outra direção. 


Resolva o problema da janta dos filósofos usando monitores, em vez de semáforos. 


Adicione código no núcleo do MINIX 3 para monitorar o número de mensagens enviadas do pro- 
cesso (ou tarefa) i para o processo (ou tarefa) j. Imprima essa matriz quando a tecla F4 for pressio- 
nada. 


Modifique o escalonador do MINIX 3 para monitorar quanto tempo da CPU cada processo de 
usuário recebeu recentemente. Quando nenhuma tarefa ou servidor quiser executar, escolha o pro- 
cesso de usuário que recebeu a menor fatia da CPU. 


Modifique o MINIX 3 de modo que cada processo possa configurar explicitamente a prioridade da 
escalonamento de seus filhos, usando uma nova chamada de sistema setpriority, com parâmetros 
pid e priority. 


Modifique as macros hwint master e hwint slave em mpx386.s de modo que, agora, as operações 
executadas pela função save sejam inline. Qual é o custo em termos do tamanho do código”? Você 
consegue medir um aumento no desempenho? 


Explique todos os itens exibidos pelo comando sysenv do MINIX 3 em seu sistema MINIX 3. Se 
você não tiver acesso a um sistema MINIX 3 em funcionamento, explique os itens da Figura 2-37. 


Na discussão sobre inicialização da tabela de processos, mencionamos que alguns compiladores C 
podem gerar um código ligeiramente melhor, se você adicionar uma constante no array, em vez do 
índice. Escreva dois programas curtos em C para testar essa hipótese. 


Modifique o MINIX 3 para reunir estatísticas sobre as mensagens enviadas por quem e para quem, 
e escreva um programa para reunir e imprimir essas estatísticas de uma maneira útil. 


3.1 


ENTRADA/SAÍDA 


Uma das principais funções de um sistema operacional é controlar todos os dispositivos de 
E/S (Entrada/Saída) do computador. Ele precisa enviar comandos para os dispositivos, cap- 
turar interrupções e tratar de erros. Também deve fornecer uma interface simples e fácil de 
usar entre os dispositivos e o restante do sistema. Na medida do possível, a interface deve ser 
a mesma para todos os dispositivos (independência de dispositivo). O código de E/S repre- 
senta uma parte significativa do sistema operacional como um todo. Assim, para realmente 
entender o que um sistema operacional faz você precisa compreender como funciona a E/S. O 
modo como o sistema operacional gerencia a E/S é o principal assunto deste capítulo. 

Este capítulo está organizado como segue. Primeiramente, veremos alguns dos prin- 
cípios da organização do hardware de E/S. Em seguida, examinaremos o software de E/S 
em geral. O software de E/S pode ser estruturado em camadas, com cada camada tendo uma 
tarefa bem definida a executar. Estudaremos essas camadas para vermos o que elas fazem e 
como se encaixam. 

Logo após, vem uma seção sobre impasses. Definiremos os impasses precisamente, 
mostraremos como eles são causados, forneceremos dois modelos para analisá-los e discuti- 
remos alguns algoritmos para evitar sua ocorrência. 

Em seguida, passaremos a ver o MINIX 3. Começaremos com uma visão geral da E/S 
no MINIX 3, incluindo interrupções, drivers de dispositivo, E/S dependente de dispositivo 
e E/S independente de dispositivo. Depois dessa introdução, veremos vários dispositivos de 
E/S em detalhes: discos, teclados e vídeo. Para cada dispositivo, estudaremos seu hardware 
e software. 


PRINCÍPIOS DO HARDWARE DE E/S 


Diferentes pessoas vêem o hardware de E/S de diferentes maneiras. Os engenheiros elétricos 
o vêem em termos de chips, fios, fontes de alimentação, motores e todos os outros componen- 
tes físicos que compõem o hardware. Os programadores vêem a interface apresentada para 
o software — os comandos aceitos pelo hardware, as funções que ele executa e os erros que 
podem ser informados. Neste livro, estamos preocupados com a programação de dispositivos 
de E/S e não com o seu projeto, construção ou manutenção; portanto, nosso interesse estará 
restrito à programação do hardware e não no seu funcionamento interno. Contudo, muitas 
vezes a programação de muitos dispositivos de E/S está intimamente ligada à sua operação 
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3.1.2 


interna. Nas próximas três subseções, ofereceremos uma breve base geral sobre hardware de 
E/S no que diz respeito à programação. 


Dispositivos de E/S 


Grosso modo, os dispositivos de E/S podem ser divididos em duas categorias: dispositivos 
de bloco e dispositivos de caractere. Um dispositivo de bloco armazena informações em 
blocos de tamanho fixo, cada um com seu próprio endereço. Os tamanhos de bloco comuns 
variam de 512 a 32.768 bytes. A propriedade fundamental de um dispositivo de bloco é que 
é possível ler ou escrever cada bloco independentemente de todos os outros. Os discos são os 
dispositivos de bloco mais comuns. 

Se você olhar de perto, não há uma divisão clara entre os dispositivos que são endereçá- 
veis por blocos e os que não são. Todo mundo concorda que um disco é um dispositivo ende- 
reçável por blocos porque, independente de onde esteja o braço do disco em dado momento, 
sempre é possível buscar outro cilindro e, então, esperar que o bloco solicitado passe sob o 
cabeçote. Agora, considere uma unidade de fita usada para fazer backups de disco. As fitas 
contêm uma seqiiência de blocos. Se a unidade de fita receber um comando para ler o bloco 
N, ela sempre poderá retroceder e avançar a fita até chegar a esse bloco. Essa operação é aná- 
loga a um disco fazendo uma busca, exceto que demora muito mais. Além disso, pode ou não 
ser possível reescrever um bloco no meio de uma fita. Mesmo que fosse possível usar fitas 
como dispositivos de bloco de acesso aleatório, isso seria forçar a sua natureza: normalmente, 
elas não são utilizadas dessa maneira. 

O outro tipo de dispositivo de E/S é o dispositivo de caractere. Um dispositivo de carac- 
tere envia ou aceita um fluxo de caracteres, sem considerar nenhuma estrutura de bloco. Ele 
não é endereçável e não tem nenhuma operação de busca. As impressoras, interfaces de rede, 
mouses (para apontar) e a maioria dos outros dispositivos que não são do tipo disco podem 
ser vistos como dispositivos de caractere. 

Essa classificação não é perfeita. Alguns dispositivos simplesmente não se encaixam. 
Os relógios, por exemplo, não são endereçáveis por bloco. Tampouco eles geram ou aceitam 
fluxos de caracteres. Tudo que eles fazem é causar interrupções em intervalos bem definidos. 
Apesar disso, o modelo de dispositivos de bloco e de caractere é geral o suficiente para poder 
ser utilizado como base para fazer uma parte do software do sistema operacional tratar com 
E/S independente de dispositivo. O sistema de arquivos, por exemplo, trata somente com 
dispositivos de bloco abstratos e deixa a parte dependente de dispositivo para um software de 
nível mais baixo, chamado driver de dispositivo. 

Os dispositivos de E/S têm uma variação enorme em suas velocidades, o que impõe 
uma pressão considerável no software para funcionar bem com diferentes taxas de dados. 
A Figura 3-1 mostra as taxas de dados de alguns dispositivos comuns. A maior parte desses 
dispositivos tende a ficar mais rápida à medida que o tempo passa. 


Controladoras de dispositivo 


Normalmente, as unidades de E/S consistem em um componente mecânico e um componente 
eletrônico. Frequentemente é possível separar as duas partes para fornecer um projeto mais 
modular e geral. O componente eletrônico é chamado de controladora de dispositivo ou 
adaptador. Nos computadores pessoais, ele frequentemente assume a forma de uma placa de 
circuito impresso que pode ser inserida em um slot de expansão. O componente mecânico é o 
dispositivo em si. Essa organização aparece na Figura 3-2 

Normalmente, a placa controladora contém um conector, no qual pode ser ligado um 
cabo que vai até o dispositivo em si. Muitas controladoras podem manipular dois, quatro ou 
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Dispositivo Taxa de dados 
Teclado 10 bytes/s 
Mouse 100 bytes/s 
Modem de 56K 7 KB/s 
Scanner 400 KB/s 
Camcorder digital 4 MB/s 
CD-ROM de 52x 8 MB/s 
FireWire (IEEE 1394) 50 MB/s 
USB 2.0 60 MB/s 
Monitor XGA 60 MB/s 
Rede SONET 0C-12 78 MB/s 
Gigabit Ethernet 125 MB/s 
Disco serial ATA 200 MB/s 
Disco SCSI Ultrawide 4 320 MB/s 
Barramento PCI 528 MB/s 


Figura 3-1 Algumas taxas de dados típicas de dispositivo, rede e barramento. 


até oito dispositivos idênticos. Se a interface entre a controladora e o dispositivo for padro- 
nizada, como uma interface ANSI, IEEE ou um padrão ISO oficial, ou de fato, então as em- 
presas poderão fazer controladores ou dispositivos que se encaixem nessa interface. Muitas 
empresas, por exemplo, produzem unidades de disco que combinam com as interfaces IDE 
(Integrated Drive Electronics) e SCSI (Small Computer System Interface). 

Mencionamos essa distinção entre controladora e dispositivo porque o sistema opera- 
cional quase sempre lida com a controladora e não com o dispositivo. A maioria dos compu- 
tadores pessoais e dos servidores utiliza o modelo de barramento da Figura 3-2 para comu- 
nicação entre a CPU e as controladoras. Os computadores de grande porte frequentemente 
utilizam um modelo diferente, com computadores de E/S especializados, chamados canais 
de E/S, que assumem parte da carga da CPU principal. 


Monitor 


Unidade de 
disco rígido 


Controladora 
de disco 
rígido 


E Controladora| |Controladora| |Controladora 


Barramento 


Figura 3-2 Um modelo para conectar a CPU, a memória, as controladoras e os dispositivos 
de E/S. 
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3.1.3 


Freqiientemente, a interface entre a controladora e o dispositivo é de baixo nível. Um 
disco, por exemplo, poderia ser formatado com 1024 setores de 512 bytes por trilha. Entre- 
tanto, o que realmente sai da unidade de disco é um fluxo serial de bits, começando com um 
preâmbulo, seguido dos 4096 bits de um setor (512 x 8 bits) e, finalmente, uma soma de 
verificação, também chamada de Código de Correção de Erros (ECC - Error-Correcting 
Code). O preâmbulo é gravado quando o disco é formatado e contém o número do cilindro e 
do setor, o tamanho do setor e dados similares. 

A tarefa da controladora é converter o fluxo serial de bits em um bloco de bytes e 
realizar toda correção de erro necessária. Normalmente, o bloco de bytes é primeiramente 
montado, bit a bit, em um buffer dentro da controladora. Depois que sua soma de verificação 
tiver sido verificada e o bloco declarado como livre de erros, ele poderá então ser copiado na 
memória principal. 

A controladora de um monitor também funciona como um dispositivo serial de bits, 
em um nível igualmente baixo. Ela lê na memória os bytes que contêm os caracteres a serem 
exibidos e gera os sinais usados para modular o feixe de elétrons do tubo de raios catódicos 
(CRT). A controladora também gera os sinais para fazer um feixe CRT realizar o retraço ho- 
rizontal, após ele ter terminado uma linha de varredura, assim como os sinais para fazer um 
retraço vertical, após a tela inteira ter sido varrida. Em uma tela LCD esses sinais selecionam 
pixels individuais e controlam seu brilho, simulando o efeito do feixe de elétrons de um CRT. 
Se não fosse a controladora de vídeo, o programador de sistema operacional teria de progra- 
mar a varredura explicitamente. Com ela, o sistema operacional inicializa a controladora com 
alguns parâmetros, como o número de caracteres ou pixels por linha e o número de linhas por 
tela, e deixa que ela se encarregue de fazer a exibição. 

As controladoras de alguns dispositivos, especialmente a dos discos, estão se tornando 
extremamente sofisticadas. Por exemplo, as controladoras de disco modernas frequentemen- 
te têm internamente vários megabytes de memória. Como resultado, quando uma leitura 
está sendo processada, assim que o braço chega ao cilindro correto, a controladora começa 
a ler e armazenar dados, mesmo que ainda não tenha chegado ao setor necessário. Esses da- 
dos colocados na cache podem ser úteis para atender requisições subsegiientes. Além disso, 
mesmo após os dados solicitados serem obtidos, a controladora pode continuar a colocar 
na cache dados de setores subseqiientes, pois eles provavelmente serão necessários poste- 
riormente. Dessa maneira, muitas leituras de disco podem ser manipuladas sem qualquer 
atividade do disco. 


E/S mapeada em memória 


Cada controladora tem alguns registradores utilizados para comunicação com a CPU. Escre- 
vendo nesses registradores, o sistema operacional pode fazer o dispositivo enviar dados, acei- 
tar dados, ligar-se ou desligar-se, ou executar alguma outra ação. Lendo esses registradores, o 
sistema operacional pode saber qual é o estado do dispositivo, se ele está pronto para aceitar 
um novo comando etc. 

Além dos registradores de controle, muitos dispositivos possuem um buffer de dados 
que o sistema operacional pode ler e escrever. Por exemplo, uma maneira comum de os com- 
putadores exibirem pixels na tela é por meio de uma memória RAM de vídeo (que basica- 
mente é apenas um buffer de dados), disponível para programas ou para o sistema operacio- 
nal escreverem. 

Surge assim o problema de como a CPU se comunica com os registradores de controle 
e com os buffers de dados dos dispositivos. Existem duas alternativas. Na primeira estratégia, 
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cada registrador de controle recebe um número de porta de E/S, um valor inteiro de 8 ou de 
16 bits. Usando uma instrução de E/S especial, como 


IN REG,PORT 


a CPU pode ler o registrador de controle PORT e armazenar o resultado no registrador REG 
da CPU. Analogamente, usando 


OUT PORT,REG 


a CPU pode escrever o conteúdo de REG em um registrador de controle. A maioria dos pri- 
meiros computadores, incluindo praticamente todos os de grande porte, como o IBM 360 e 
todos os seus sucessores, funcionavam dessa maneira. 

Nesse esquema, os espaços de endereçamento da memória e da E/S são diferentes, 
como se vê na Figura 3-3(a). 


Um espaço de Dois espaços 
Dois endereços endereçamento de endereçamento 


OxFFFF... Memória 


Portas de E/S 


o E [ 
(a) (b) (c) 


Figura 3-3 (a) Espaço de E/S e de memória separados. (b) E/S mapeada em memória. (c) 
Misto. 


Em outros computadores, os registradores de E/S fazem parte do espaço de endereça- 
mento normal da memória, como se vê na Figura 3-3(b). Esse esquema é chamado de E/S 
mapeada em memória e foi introduzido com o minicomputador PDP-11. Cada registrador 
de controle recebe um endereço exclusivo ao qual nenhuma memória é atribuída. Normal- 
mente, os endereços atribuídos estão no topo do espaço de endereçamento. Um esquema 
misto, com buffers de dados de E/S mapeados em memória e portas de E/S separados para os 
registradores de controle, aparece na Figura 3-3(c). O Pentium usa essa arquitetura, com os 
endereços de 640K a 1M reservados para buffers de dados de dispositivo, em computadores 
compatíveis com o IBM PC, além de portas de E/S de O a 64K. 

Como esses esquemas funcionam? Em todos os casos, quando a CPU quer ler uma 
palavra, ou da memória ou de uma porta de E/S, ela coloca o endereço necessário nas linhas 
de endereço do barramento e, então, envia um sinal READ em uma linha de controle do barra- 
mento. Uma segunda linha de sinal é usada para dizer se é necessário espaço de E/S ou espa- 
ço de memória. Se for espaço de memória, a memória responderá a requisição. Se for espaço 
de E/S, é o dispositivo de E/S que responderá. Se houver apenas espaço de memória (como 
na Figura 3-3(b)), todo módulo de memória e todo dispositivo de E/S compara as linhas de 
endereço com o intervalo de endereços que ele atende. Se o endereço cair em seu intervalo, 
ele responderá ao pedido. Como jamais um endereço é atribuído simultaneamente à memória 
e a um dispositivo de E/S, não há nenhuma ambigiiidade e nenhum conflito. 
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3.1.5 


Interrupções 


Normalmente, os registradores da controladora têm um ou mais bits de status que podem ser 
testados para determinar se uma operação de saída está concluída ou se novos dados estão 
disponíveis em um dispositivo de entrada. Uma CPU pode executar um laço, sempre testando 
um bit de status, até que um dispositivo esteja pronto para aceitar ou fornecer novos dados. 
Isso é chamado de consulta segiiencial (polling) ou espera ativa (busy wait). Vimos esse 
conceito na Seção 2.2.3 como um possível método para tratar com seções críticas e, naquele 
contexto, ele foi rejeitado como algo a ser evitado na maioria das circunstâncias. No âmbito 
da E/S, onde você pode ter de esperar por um tempo muito longo para que o mundo externo 
aceite ou produza dados, a consulta sequencial não é aceitável, exceto para sistemas dedica- 
dos muito pequenos, que não executam múltiplos processos. 

Além dos bits de status, muitas controladoras utilizam interrupções para informar à 
CPU quando estão prontas para ter seus registradores lidos ou escritos. Vimos na Seção 2.1.6 
como as interrupções são manipuladas pela CPU. No contexto da E/S, tudo que você precisa 
saber é que a maioria dos dispositivos de interface fornece uma saída que é logicamente igual 
ao bit de status de “operação completa” ou “dados prontos” de um registrador, mas que se 
destina a ser usada para estimular uma das linhas de pedido de interrupção (IRQ — Interrupt 
ReQuest) do barramento do sistema. Assim, quando uma operação termina, ela interrompe 
a CPU e começa a executar a rotina de tratamento de interrupção. Esse código informa ao 
sistema operacional que a E/S está concluída. O sistema operacional pode então verificar os 
bits de status para saber se tudo correu bem e recuperar os dados resultantes ou iniciar uma 
nova tentativa. 

O número de entradas na controladora de interrupção pode ser limitado; os PCs da clas- 
se Pentium têm apenas 15, para dispositivos de E/S. Algumas controladoras são conectadas 
diretamente na placa-mãe do sistema; por exemplo, as controladoras de disco e teclado de um 
IBM PC. Nos sistemas mais antigos, a IRQ usada por dispositivos era configurado por meio 
de chaves ou jumpers associados às controladoras. Se o usuário comprasse um novo dispo- 
sitivo, tinha de configurar a IRQ manualmente, para evitar conflitos com as IRQs existentes. 
Poucos usuários conseguiam fazer isso corretamente, o que levou a indústria a desenvolver a 
tecnologia Plug’n Play, na qual a BIOS pode atribuir IRQs automaticamente para os disposi- 
tivos no momento da inicialização, evitando, assim, conflitos. 


Acesso direto à memória 


Tenha ou não E/S mapeada em memória, a CPU de um sistema precisa endereçar as controla- 
doras de dispositivo para trocar dados com elas. A CPU pode solicitar dados de uma controla- 
dora de E/S um byte por vez, mas fazer isso para um dispositivo como um disco, que produz 
um bloco de dados grande, desperdiçaria muito tempo de CPU; portanto fregiientemente é 
usado um esquema diferente, chamado Acesso Direto à Memória (DMA - Direct Memory 
Access). O sistema operacional só pode usar DMA se o hardware tiver uma controladora de 
DMA, o que a maioria dos sistemas possui. Às vezes, essa controladora é integrada nas con- 
troladoras de disco e em outras, mas tal projeto exige uma controladora de DMA separada 
para cada dispositivo. Mais comumente, é disponível uma única controladora de DMA (por 
exemplo, na placa-mãe) para regular as transferências dos vários dispositivos de E/S, muitas 
vezes de forma concomitante. 

Não importa onde esteja localizada fisicamente, a controladora de DMA tem acesso ao 
barramento do sistema independente da CPU, como se vê na Figura 3-4. Ela contém vários 
registradores que podem ser escritos e lidos pela CPU. Isso inclui um registrador de endere- 
ços de memória, um registrador contador de bytes e um ou mais registradores de controle. Os 
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registradores de controle especificam a porta de E/S a ser usada, a direção da transferência 
(leitura ou escrita do dispositivo de E/S), a unidade de transferência (um byte ou uma palavra 
por vez) e o número de bytes a transferir em uma rajada. 


Se Unidade de disco 
1.A CPU 
programa a Controladora Controladora Memória 
CPU controladora de DMA de disco principal 


de DMA 


4. Sinal de 


Endereço | Ireconhecimento 


Interrompe 2.0 DMA solicita 
h transferência para : 
ao terminar a padrao 3. Dados transferidos 


-<— Barramento 


Figura 3-4 Operação de uma transferência de DMA. 


Para explicarmos o funcionamento do DMA, vamos primeiro ver como ocorrem as lei- 
turas de disco quando o DMA não é utilizado. Primeiramente, a controladora lê o bloco (um 
ou mais setores) da unidade de disco em série, bit por bit, até que o bloco inteiro esteja em 
seu buffer interno. Em seguida, ela calcula a soma de verificação para verificar se não ocor- 
reu nenhum erro de leitura. Então, a controladora causa uma interrupção. Quando o sistema 
operacional começa a executar, ele pode ler o bloco de disco do buffer da controladora, um 
byte ou palavra por vez, executando um laço, com cada iteração lendo um byte ou palavra de 
um registrador de dispositivo da controladora, armazenando-o na memória principal, incre- 
mentando o endereço de memória e decrementando a contagem de itens a serem lidos até que 
ela chegue a zero. 

Quando o DMA é usado, o procedimento é diferente. Primeiramente, a CPU programa 
a controladora de DMA, configurando seus registradores para saber o que deve transferir e 
para onde (etapa 1 na Figura 3-4). Ela também envia um comando para a controladora de 
disco, dizendo a ela para que leia dados do disco em seu buffer interno e confira a soma de 
verificação. Quando dados válidos estiverem no buffer da controladora de disco, o DMA 
poderá começar. 

A controladora de DMA inicia a transferência enviando uma requisição de leitura para 
a controladora de disco pelo barramento (etapa 2). Essa requisição de leitura é semelhante as 
outras e a controladora de disco não sabe, nem se preocupa, se ele veio da CPU ou de uma 
controladora de DMA. Normalmente, o endereço de memória a ser escrita é posto nas linhas 
de endereçamento do barramento, de modo que, quando a controladora de disco busca a 
próxima palavra de seu buffer interno, ela sabe onde escrevê-la. A escrita na memória é outro 
ciclo de barramento padrão (etapa 3). Quando a escrita termina, a controladora de disco envia 
um sinal de reconhecimento (ack — acknowledgement) para a controladora de DMA, também 
pelo barramento (etapa 4). Então, a controladora de DMA incrementa o endereço de memória 
a ser usado e decrementa a contagem de bytes. Se a contagem de bytes ainda for maior do 
que 0, as etapas 2 a 4 serão repetidas, até que ela chegue a 0. Nesse ponto, a controladora 
causa uma interrupção. Quando o sistema operacional inicia, não precisa copiar o bloco na 
memória; o bloco já está lá. 
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3.2 


3.2.1 


Talvez você esteja se perguntando por que a controladora simplesmente não armazena 
os bytes na memória principal assim que os recebe do disco. Em outras palavras, por que ela 
precisa de um buffer interno? Existem dois motivos. Primeiramente, usando o buffer interno, 
a controladora de disco pode conferir a soma de verificação antes de iniciar uma transferên- 
cia. Se a soma de verificação estiver incorreta, um erro será sinalizado e nenhuma transferên- 
cia para a memória será feita. 

O segundo motivo é que, uma vez iniciada uma transferência de disco, os bits continu- 
arão chegando do disco a uma velocidade constante, esteja a controladora pronta para eles ou 
não. Se a controladora tentasse escrever os dados diretamente na memória, ela teria que usar 
o barramento do sistema para cada palavra transferida. Se o barramento estivesse ocupado 
por algum outro dispositivo que o estivesse usando, a controladora teria de esperar. Se a pró- 
xima palavra do disco chegasse antes que a anterior tivesse sido armazenada, a controladora 
precisaria armazená-la em algum outro lugar. Se o barramento estivesse muito ocupado, a 
controladora poderia acabar armazenando muitas palavras e também tendo muita administra- 
ção a fazer. Quando o bloco é colocado no buffer internamente, o barramento não é necessá- 
rio até que o DMA comece; portanto, o projeto da controladora é muito mais simples, pois a 
transferência de DMA para a memória não crítica com relação ao tempo. 

Nem todos os computadores utilizam DMA. O argumento contra ele é que a CPU prin- 
cipal frequentemente é muito mais rápida do que a controladora de DMA e pode fazer o 
trabalho com velocidade muito maior (quando o fator limitante não é a velocidade do dis- 
positivo de E/S). Se não houver nenhum outro trabalho para ela, não tem sentido fazer a 
CPU (rápida) esperar que a controladora de DMA (lenta) termine. Além disso, livrar-se da 
controladora de DMA e fazer com que a CPU realize todo o trabalho no software significa 
economia de dinheiro, o que é importante em sistemas de baixo custo ou portáteis como os 
sistemas embarcados. 


PRINCÍPIOS DO SOFTWARE DE E/S 


Vamos agora deixar o hardware de E/S de lado e ver o aspecto software. Primeiramente, vere- 
mos os objetivos do software de E/S e, depois, as diferentes maneiras pelas quais a E/S pode 
ser feita do ponto de vista do sistema operacional. 


Objetivos do software de E/S 


Um conceito importante no projeto de software de E/S é a independência de dispositivo. 
Isso significa que deve ser possível escrever programas que possam acessar qualquer disposi- 
tivo de E/S sem a necessidade de especificar o dispositivo antecipadamente. Por exemplo, um 
programa que lê um arquivo como entrada deve ser capaz de ler um arquivo em um disquete, 
em um disco rígido ou em um CD-ROM, sem precisar ser modificado para cada dispositivo 
diferente. Analogamente, qualquer pessoa deve ser capaz de digitar um comando como 


sort <input >output 


e fazê-lo funcionar com a entrada proveniente de um disquete, de um disco IDE, de um 
disco SCSI ou do teclado, e ter a saída indo para qualquer tipo de disco ou para a tela. Cabe 
ao sistema operacional resolver os problemas causados pelo fato desses dispositivos serem 
diferentes e exigirem sequências de comandos muito diferentes para operações de leitura ou 
de escrita. 

Intimamente relacionado à independência de dispositivo é o objetivo da atribuição 
uniforme de nomes. O nome de um arquivo ou de um dispositivo deve ser simplesmente 
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uma string ou um inteiro e de modo algum deve depender do dispositivo. No UNIX e no 
MINIX 3, todos os discos podem ser integrados na hierarquia do sistema de arquivos de 
maneiras arbitrárias, de modo que o usuário não precisa saber qual nome corresponde a 
qual dispositivo. Por exemplo, um disquete pode ser montado na raiz do diretório /usr/ast/ 
backup, de modo que copiar um arquivo para esse diretório significa copiá-lo no disquete. 
Desse modo, todos os arquivos e dispositivos são endereçados da mesma maneira: por um 
nome de caminho. 

Outra questão importante para o software de E/S é o tratamento de erros. Em geral, 
os erros devem ser tratados o mais próximo do hardware possível. Se a controladora descobre 
um erro de leitura, ela mesma deve tentar corrigi-lo, se puder. Se não puder, então o driver de 
dispositivo deverá tratar dele, talvez apenas tentando ler o bloco novamente. Muitos erros são 
passageiros, como os erros de leitura causados por partículas de poeira no cabeçote de leitura, 
e desaparecerão se a operação for repetida. Somente se as camadas mais baixas não forem ca- 
pazes de lidar com o problema é que as camadas mais altas devem ser informadas. Em muitos 
casos, a recuperação do erro pode ser feita de modo transparente em um nível baixo, sem que 
os níveis superiores nem mesmo saibam a respeito dele. 

Outra questão importante são as transferências síncronas (com bloqueio) versus as- 
síncronas (baseadas em interrupções). A maior parte da E/S física é assíncrona — a CPU 
inicia a transferência e vai fazer outra coisa, até a chegada da interrupção. Os programas de 
usuário são muito mais fáceis de escrever se as operações de E/S causam bloqueio — após 
uma chamada de sistema receive, o programa é automaticamente suspenso até que os dados 
estejam disponíveis no buffer. Cabe ao sistema operacional fazer com que as operações que, 
na verdade, são baseadas em interrupções, se pareçam com bloqueios para os programas de 
usuário. 

Uma outra questão para o software de E/S é o uso de buffers. Frequentemente, os da- 
dos provenientes de um dispositivo não podem ser armazenados diretamente em seu destino 
final. Por exemplo, quando um pacote vem da rede, o sistema operacional não sabe onde co- 
locá-lo, até o ter armazenado em algum lugar e examiná-lo. Além disso, alguns dispositivos 
têm restrições de tempo real severas (por exemplo, os dispositivos de áudio digital) de modo 
que os dados devem ser colocados antecipadamente em um buffer de saída para desvincular a 
velocidade com que o buffer é preenchido da velocidade com que ele é esvaziado, para evitar 
a falta de dados. O uso de buffers envolve um volume de cópias considerável e fregientemen- 
te tem um impacto importante sobre o desempenho das operações de E/S. 

O último conceito que mencionaremos aqui são os dispositivos que podem ser compar- 
tilhados versus dispositivos dedicados. Alguns dispositivos de E/S, como os discos, podem 
ser empregados por muitos usuários ao mesmo tempo. Nenhum problema é causado pelo 
fato de vários usuários terem arquivos abertos, no mesmo disco, ao mesmo tempo. Outros 
dispositivos, como as unidades de fita, precisam ser dedicados a um único usuário até que ele 
tenha terminado de usá-la. Então, outro usuário pode utilizar a unidade de fita. Ter dois ou 
mais usuários escrevendo blocos misturados aleatoriamente na mesma fita definitivamente 
não funciona. A introdução de dispositivos dedicados (não compartilhados) também apre- 
senta uma variedade de problemas, como os impasses (deadlocks). Novamente, o sistema 
operacional deve ser capaz de manipular tanto dispositivos dedicados quanto compartilhados, 
de uma maneira que evite problemas. 

Fregiientemente, o software de E/S é organizado em quatro camadas, como se vê na Fi- 
gura 3-5. Nas subseções a seguir, veremos cada uma delas por vez, começando com a inferior. 
A ênfase deste capítulo são os drivers de dispositivo (camada 2), mas resumiremos o restante 
do software de E/S para mostrar como as partes do sistema de E/S se encaixam. 


CAPÍTULO 3 é ENTRADA/SAÍDA 225 


3.2.2 


3.2.3 


Figura 3-5 Camadas do sistema de software de E/S. 


Rotinas de tratamento de interrupção 


As interrupções são uma realidade desagradável; embora não possam ser evitadas. Elas de- 
vem ser bem ocultadas no interior do sistema operacional, para que o mínimo possível do sis- 
tema saiba a seu respeito. A melhor maneira de ocultá-las é fazer com que o driver que inicia 
uma operação de E/S seja bloqueado até que a E/S tenha terminado e a interrupção associada 
ocorra. O driver se bloquear sozinho, usando-se, por exemplo, uma instrução down em um 
semáforo, uma instrução wait em uma variável de condição, uma instrução receive em uma 
mensagem ou algo semelhante. 

Quando a interrupção acontece, a função de tratamento faz o que for necessário para 
atendê-la. Então, ela pode desbloquear o driver que a iniciou. Em alguns casos, ela apenas 
completará uma instrução up em um semáforo. Em outros, executará uma instrução signal 
em uma variável de condição em um monitor. Ainda, em outros casos, ela enviará uma men- 
sagem para o driver bloqueado. Em todos os casos, o efeito geral da interrupção será que 
um driver que anteriormente estava bloqueado agora poderá executar. Esse modelo funciona 
melhor se os drivers forem estruturados como processos independentes, com seus próprios 
estados, pilhas e contadores de programa. 


Drivers de dispositivo 


Anteriormente neste capítulo, vimos que cada controlador de dispositivo possui registradores 
utilizados para fornecer comandos ou para ler seu status (ou ambos). O número de registrado- 
res e a natureza dos comandos variam radicalmente de um dispositivo para outro. Por exem- 
plo, um driver de mouse precisa aceitar informações do mouse dizendo quanto ele se moveu e 
quais botões estão sendo pressionados no momento. Em contraste, um driver de disco precisa 
saber a respeito de setores, trilhas, cilindros, cabeçotes, movimento do braço, propulsão do 
motor, tempos de acomodação do cabeçote e todos os outros fatores mecânicos necessários 
para fazer o disco funcionar corretamente. Obviamente, esses drivers serão muito diferentes. 

Assim, cada dispositivo de E/S ligado a um computador precisa de algum código espe- 
cífico do dispositivo para controlá-lo. Esse código, cnamado de driver de dispositivo, geral- 
mente é escrito pelo fabricante do dispositivo e distribuído junto com ele em um CD-ROM. 
Como cada sistema operacional precisa de seus próprios drivers, os fabricantes de dispositivo 
normalmente fornecem drivers para vários sistemas operacionais populares. 

Normalmente, cada driver de dispositivo manipula um tipo de dispositivo ou uma classe 
de dispositivos intimamente relacionados. Por exemplo, provavelmente seria uma boa idéia 
ter um único driver de mouse, mesmo que o sistema suporte várias marcas diferentes de mou- 
se. Como outro exemplo, um driver de disco normalmente pode manipular vários discos de 
diferentes tamanhos e velocidades, e talvez também um CD-ROM. Por outro lado, um mouse 
e um disco são tão diferentes, que são necessários drivers diferentes. 
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Para acessar o hardware do dispositivo (quer dizer, os registradores da controladora), 
tradicionalmente, o driver de dispositivo faz parte do núcleo do sistema. Essa estratégia ofe- 
rece o melhor desempenho e a pior confiabilidade, pois um erro em qualquer driver de dis- 
positivo pode derrubar o sistema inteiro. O MINIX 3 diverge desse modelo para melhorar 
a confiabilidade. Conforme veremos, no MINIX 3, cada driver de dispositivo agora é um 
processo separado em modo usuário. 

Conforme mencionamos anteriormente, os sistemas operacionais normalmente classi- 
ficam os drivers como dispositivos de bloco (como os discos) ou como dispositivos de ca- 
ractere (como os teclados e as impressoras). A maioria dos sistemas operacionais define uma 
interface padrão que todos os drivers de bloco devem suportar e uma segunda interface pa- 
drão que todos os drivers de caractere devem suportar. Essas interfaces consistem em várias 
funções que o restante do sistema operacional pode chamar para fazer o driver trabalhar. 

Em termos gerais, a tarefa de um driver de dispositivo é aceitar requisições abstratas do 
software independente de dispositivo (que está acima dele) e cuidar para que as requisições 
sejam executadas. Uma requisiçõa típica para um driver de disco é ler o bloco n. Se o driver 
estiver ocioso no momento da chegada de uma requisição, ele começará a executá-la imedia- 
tamente. Entretanto, se ele já estiver ocupado, normalmente colocará a nova requisição em 
uma fila de requisições pendentes para serem tratadas assim que for possível. 

O primeiro passo na execução de uma requisição de E/S é verificar se os parâmetros de 
entrada são válidos e, caso não sejam, retornar um erro. Se a requisição for válida, o próximo 
passo será transformá-la dos termos abstratos para concretos. Para um driver de disco, isso 
significa descobrir onde o bloco solicitado está realmente no disco, verificar se o motor da 
unidade de disco está funcionando, determinar se o braço está posicionado no cilindro correto 
etc. Em resumo, o driver deve decidir quais operações da controladora são exigidas e em que 
sequência. 

Uma vez que o driver tiver determinado quais comandos deve enviar para a controlado- 
ra, ele começará a executá-los, escrevendo nos registradores de dispositivo da controladora. 
As controladoras simples podem manipular apenas um comando por vez. As controladoras 
mais sofisticadas aceitam uma lista encadeada de comandos, os quais serão executados sem a 
intervenção do sistema operacional. 

Após o comando (ou comandos) ter sido executado, ocorre uma de duas situações. Em 
muitos casos, o driver de dispositivo deve esperar até que a controladora realize algum traba- 
lho para ele; portanto, ele bloqueia a si mesmo até que a interrupção entre para desbloqueá-lo. 
Em outros casos, entretanto, a operação é executada rapidamente, de modo que o driver não 
precisa ser bloqueado. Como exemplo desta última situação, em algumas placas gráficas, 
rolar a tela exige apenas escrever alguns bytes de comando nos registradores da controladora. 
Nenhum movimento mecânico é necessário; portanto, a operação inteira pode ser concluída 
em poucos microssegundos. 

No primeiro caso, o driver será desbloqueado pela ocorrência da interrupção. No se- 
gundo caso, ele nunca será bloqueado. De qualquer modo, após a operação ter terminado, ele 
deve verificar a existência de erros. Se tudo estiver correto, o driver poderá ter dados para 
passar para o software independente de dispositivo (por exemplo, um bloco que acabou de ser 
lido). Finalmente, ele retorna algumas informações de status para informar situações de er- 
ros, ou não, para quem o chamou. Se houver outras requisições enfileiradas, agora uma delas 
poderá ser selecionada e iniciada. Se nada estiver enfileirado, o driver será bloqueado e ficará 
aguardando a próxima requisição. 

Tratar com requisições de leitura e gravação é a principal função de um driver, mas 
pode haver outros requisitos. Por exemplo, talvez o driver precise configurar um dispositivo 
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no momento que o sistema está sendo inicializado ou na primeira vez que ele for usado. 
Além disso, pode haver necessidade de gerenciar requisitos de energia, manipular dispositi- 
vos Plug 'n Play ou tratar de eventos de log. 


Software de E/S independente de dispositivo 


Embora um trecho do software de E/S seja específico a um dispositivo, uma grande parte dele 
é independente deste. O limite exato entre os drivers e o software independente de dispositivo 
depende do sistema, pois algumas funções que poderiam ser executadas de maneira indepen- 
dente de dispositivo podem, na verdade, por eficiência ou outros motivos, serem executadas 
nos drivers. As funções que aparecem na Figura 3-6 normalmente são executadas no software 
independente de dispositivo. No MINIX 3, a maioria do software independente de dispositivo 
faz parte do sistema de arquivos. Embora nosso estudo do sistema de arquivos seja deixado 
para o Capítulo 5, veremos, aqui, rapidamente, o software independente de dispositivo para 
darmos alguma perspectiva sobre a E/S e mostrarmos melhor onde os drivers se encaixam. 


Interface uniforme para drivers de dispositivo 


Buffers 


Informe de erros 


Alocação e liberação de dispositivos dedicados 
Fornecimento de um tamanho de bloco independente de dispositivo 


Figura 3-6 Funções do software de E/S independente de dispositivo. 


A função básica do software independente de dispositivo é executar as funções de E/S 
comuns a todos os dispositivos e fornecer uma interface uniforme para o software em nível de 
usuário. Veremos a seguir os problemas acima com mais detalhes. 


Interface uniforme para drivers de dispositivo 


Um problema importante em um sistema operacional é como fazer todos os dispositivos e 
drivers de E/S parecerem mais ou menos iguais. Se discos, impressoras, monitores, teclados 
etc., tiverem todos interfaces diferentes, sempre que aparecer um novo dispositivo periférico, 
o sistema operacional deverá ser modificado para esse novo dispositivo. Na Figura 3-7(a), 
ilustramos simbolicamente uma situação na qual cada driver de dispositivo tem uma interface 
diferente com o sistema operacional. Em contraste, na Figura 3-7(b), mostramos um projeto 
diferente, no qual todos os drivers têm a mesma interface. 

Com uma interface padrão é muito mais fácil de instalar um novo driver, desde que 
ele seja compatível com a interface existente. Isso também significa que os desenvolvedores 
de drivers sabem o que é esperado deles (por exemplo, quais funções eles devem fornecer 
e quais funções do núcleo eles podem chamar). Na prática, nem todos os dispositivos são 
absolutamente idênticos, mas normalmente existe apenas um pequeno número de tipos de 
dispositivo e mesmo esses geralmente são quase idênticos. Por exemplo, até os dispositivos 
de bloco e de caractere têm muitas funções em comum. 

Outro aspecto do fato de ter uma interface uniforme é o modo como os dispositivos de 
E/S são nomeados. O software independente de dispositivo cuida do mapeamento de nomes 
de dispositivo simbólicos para o driver correto. Por exemplo, no UNIX e no MINIX 3, um 
nome de dispositivo, como /dev/disk0, especifica exclusivamente o i-node de um arquivo 
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Sistema operacional Sistema operacional 


Pod a Mg oh fundo fd 


Driver de disco Driverde Driver de teclado Driver de disco - Driver de Driver de teclado 
impressora impressora 


(a) (b) 


Figura 3-7 (a) Sem uma interface de driver padrão. (b) Com uma interface de driver 
padrão. 


especial e esse i-node contém o número principal do dispositivo (major number), que é 
usado para localizar o driver apropriado. O i-node também contém o número secundário do 
dispositivo (minor number), que é passado como parâmetro para o driver, para especificar 
a unidade a ser lida ou escrita. Todos os dispositivos possuem números principais e secun- 
dários, e todos os drivers são acessados usando-se o número principal do dispositivo para 
selecionar o driver. 

Intimamente relacionada com a atribuição de nomes está a proteção. Como o sistema 
impede que os usuários acessem dispositivos que não podem acessar? No UNIX, no MINIX 
3, e também nas versões mais recentes do Windows, como o Windows 2000 e o Windows XP, 
os dispositivos aparecem no sistema de arquivos como objetos nomeados, o que significa que 
as regras de proteção normais para arquivos também se aplicam aos dispositivos de E/S. O 
administrador do sistema pode então configurar as permissões corretas (isto é, no UNIX, os 
bits rwx) para cada dispositivo. 


Uso de buffers 


O uso de buffers também é um problema tanto para dispositivos de bloco como para dis- 
positivos de caractere. Para dispositivos de bloco, o hardware geralmente insiste em ler e 
escrever blocos inteiros simultaneamente, mas os processos de usuário estão livres para ler e 
escrever em unidades arbitrárias. Se um processo de usuário escrever meio bloco, o sistema 
operacional normalmente manterá esses dados em memória até que sejam escritos os dados 
restantes, momento este em que o bloco irá para o disco. Para dispositivos de caractere, os 
dados podem ser escritos mais rapidamente do que eles podem aparecer na saída, precisando 
então do uso de buffers. Uma entrada de teclado que chega antes de ser necessária também 
exige o uso de buffers. 


Informe de erros 


Os erros são muito mais comuns no contexto da E/S do que em qualquer outro. Quando eles 
ocorrem, o sistema operacional precisa tratar deles da melhor forma possível. Muitos erros 
são específicos do dispositivo; portanto, apenas o driver sabe o que fazer (por exemplo, tentar 
novamente, ignorar ou gerar uma situação de pânico). Um erro típico é causado por um bloco 
de disco que foi danificado e não pode mais ser lido. Após o driver ter tentado ler o bloco 
certo número de vezes, ele desiste e informa o software independente de dispositivo. O modo 
como o erro é tratado a partir daí é independente do dispositivo. Se o erro ocorreu durante a 
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leitura de um arquivo de usuário, pode ser suficiente informá-lo para quem fez a chamada. 
Entretanto, se ele ocorreu durante a leitura de uma estrutura de dados fundamental para o 
sistema como, por exemplo, o bloco que contém o mapa de bits mostrando quais blocos estão 
livres, talvez o sistema operacional tenha que exibir uma mensagem de erro e terminar. 


Alocando e liberando dispositivos dedicados 


Alguns dispositivos, como os gravadores de CD-ROM, só podem ser usados por um único 
processo em dado momento. Cabe ao sistema operacional examinar as requisições de utili- 
zação do dispositivo e aceitá-los ou rejeitá-los, dependendo de o dispositivo solicitado estar 
disponível ou não. Uma maneira simples de tratar essas requisições é exigir que os processos 
executem operações open diretamente nos arquivos especiais dos dispositivos. Se o disposi- 
tivo não estiver disponível, a operação open falhará, fechando esse dispositivo dedicado e, 
então, liberando-o. 


Tamanho de bloco independente de dispositivo 


Nem todos os discos têm o mesmo tamanho de setor. Cabe ao software independente de 
dispositivo ocultar esse fato e fornecer um tamanho de bloco uniforme para as camadas su- 
periores; por exemplo, tratando vários setores como um único bloco lógico. Desse modo, as 
camadas superiores só tratam com dispositivos abstratos, todos os quais utilizam o mesmo 
tamanho de bloco lógico, independente do tamanho do setor físico. Analogamente, alguns 
dispositivos de caractere enviam seus dados um byte por vez (por exemplo, os modems), 
enquanto outros os enviam em unidades maiores (por exemplo, as interfaces de rede). Essas 
diferenças também podem ser ocultadas. 


Software de E/S em espaço de usuário 


Embora a maior parte do software de E/S esteja dentro do sistema operacional, uma peque- 
na parte dele consiste em bibliotecas ligadas ao programas do usuário e até de programas 
inteiros executando fora do espaço de endereçamento do núcleo. As chamadas de sistema, 
incluindo as de E/S, normalmente são feitas por funções de biblioteca. Quando um programa 
em C contiver a chamada 


count = write(fd, buffer, nbytes); 


a função de biblioteca write será ligada ao código-objeto do usuário e contida no programa 
binário presente na memória no momento da execução. O conjunto de todas essas funções de 
biblioteca claramente faz parte do sistema de E/S. 

Embora essas funções façam pouco mais do que colocar seus parâmetros no lugar apro- 
priado da chamada de sistema, existem outras funções de E/S que executam um trabalho real 
adicional. Em particular, a formatação da entrada e saída é feita por função de biblioteca. Um 
exemplo da linguagem C é printf, que recebe como entrada uma string de formato e possivel- 
mente algumas variáveis, constrói uma string em ASCII e, então, chama write para enviar a 
string para a saída. Como um exemplo de printf, considere a instrução 


printf(“The square of %3d is %6d\n”, i, i*i); 


Ela formata uma string consistindo na string de 14 caracteres “The square of”, seguida 
. . ~ . $ ©. 2 
do valor i como uma string de 3 caracteres e, então, da string de 4 caracteres “ is ”, depois i 
como seis caracteres e, finalmente, um avanço de linha. 
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Um exemplo de função semelhante para entrada é scanf, que lê a entrada e a armazena 
nas variáveis descritas em uma string de formato usando a mesma sintaxe de printf. A biblio- 
teca de E/S padrão contém várias funções que envolvem E/S e todas são executadas como 
parte de programas de usuário. 

Nem todo software de E/S em nível de usuário consiste em funções de biblioteca. Outra 
categoria importante é o sistema de spooling. O spool é uma maneira de tratar com disposi- 
tivos de E/S dedicados em um sistema de multiprogramação. Considere um dispositivo com 
típico com spool: uma impressora. Embora tecnicamente seja simples permitir que qualquer 
processo de usuário abra o arquivo de caracteres especial que corresponde a impressora, su- 
ponha que ele o abrisse e depois não fizesse mais nada por várias horas. Nenhum outro pro- 
cesso poderia imprimir nada. 

Em vez disso, é criado um processo especial, chamado daemon, em um diretório espe- 
cial, o diretório de spool. Para imprimir um arquivo, um processo primeiro gera o arquivo 
inteiro a ser impresso e o coloca no diretório de spool. Cabe ao daemon, que é o único proces- 
so a ter permissão para usar o arquivo especial associado a impressora, imprimir os arquivos 
no diretório. Protegendo-se o arquivo especial contra o uso direto por parte dos usuários, o 
problema de alguém deixá-lo aberto desnecessariamente por muito tempo é eliminado. 

O spool não é utilizado apenas por impressoras, mas também em várias outras situa- 
ções. Por exemplo, o correio eletrônico normalmente usa um daemon. Quando uma men- 
sagem é enviada, ela é na verdade colocada em um diretório de spool de correio eletrônico. 
Posteriormente, o daemon de correio tentará enviá-la realmente. Eventualmente, em um dado 
momento, pode não ser possível contatar o destinatário, nesse caso, o daemon deixa a mensa- 
gem no spool, com informações de status indicando que deve ser tentado um reenvio dentro 
de alguns instantes. O daemon também pode enviar um aviso para o remetente dizendo que 
o envio da mensagem foi adiado, ou, após um atraso de algumas horas, ou alguns dias, que a 
mensagem não pôde ser entregue. Tudo isso se dá fora do sistema operacional. 

A Figura 3-8 resume o sistema de E/S, mostrando as diferentes camadas e as principais 
funções de cada uma. De baixo para cima, as camadas são: o hardware, as rotinas de trata- 
mento de interrupção, os drivers de dispositivo, o software independente de dispositivo e os 
processos de usuário. 


Resposta 
Camada de E/S Funções de E/S 
Requisição Processo de usuário Faz chamada de E/S; formata a E/S; spooling 
de E/S 
Software independente Atribuição de nomes, proteção, bloqueio, 
de dispositivo uso de buffers, alocação 
Drivers de dispositivo Configura registradores de dispositivo; verifica status 
Rotinas de tratamento e. o 
de interrupção Desbloqueia driver ao término da E/S 
Hardware Executa operação de E/S 


Figura 3-8 Camadas do sistema de E/S e as principais funções de cada uma. 


As setas na Figura 3-8 mostram o fluxo de controle. Quando um programa de usuário 
tenta ler um bloco de um arquivo, por exemplo, o sistema operacional é chamado para exe- 
cutar a chamada. O software independente de dispositivo procura por esse bloco na cache 
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em memória (um tipo de buffer). Se o bloco necessário não estiver lá, ele chama o driver de 
dispositivo para enviar a requisição para o hardware, para obtê-lo do disco. Então, o processo 
é bloqueado até que a operação de disco tenha terminado. 

Quando a operação de disco tiver terminado, o hardware gerará uma interrupção. A 
rotina de tratamento de interrupção será executada para descobrir o que aconteceu; isto é, 
qual dispositivo quer ser atendido imediatamente. Então, ela extrai o status do dispositivo e 
desbloqueia o processo que estava esperando a conclusão da operação de E/S para permitir 
que o processo de usuário continue sua execução. 


3.3 IMPASSES 


Os sistemas de computador possuem vários recursos que só podem ser usados por um pro- 
cesso por vez. Exemplos comuns incluem as impressoras, unidades de fita e entradas nas 
tabelas internas do sistema. Ter dois processos escrevendo simultaneamente na impressora 
causa confusão. Ter dois processos usando a mesma entrada na tabela do sistema de arquivos 
invariavelmente levará a um sistema de arquivos corrompido. Conseqiientemente, todos os 
sistemas operacionais têm a capacidade de garantir (temporariamente) a um processo o aces- 
so exclusivo a certos recursos, tanto de hardware como de software. 

Para muitos aplicativos, um processo precisa de acesso exclusivo não para um recurso, 
mas para vários. Suponha, por exemplo, que dois processos queiram gravar em um CD um do- 
cumento escaneado. O processo A pede permissão para usar o scanner e a recebe. O processo B 
é programado de forma diferente e solicita primeiro o gravador de CD e também o recebe. Ago- 
ra, A solicita o gravador de CD, mas a requisição é negada até que B o libere. Infelizmente, em 
vez de liberar o gravador de CD, B solicita o scanner. Nesse ponto, os dois processos são blo- 
queados e permanecerão assim para sempre. Essa situação é chamada de impasse (deadlock). 

Os impasses podem ocorrer em uma variedade de situações, além da solicitação de 
dispositivos de E/S dedicados. Em um sistema de banco de dados, por exemplo, um programa 
talvez tenha que travar vários registros que está usando para evitar condições de corrida. Se o 
processo A trava o registro R7, o processo B trava o registro R2 e, então, cada processo tenta 
travar o registro do outro, também temos um impasse. Assim, os impasses podem ocorrer em 
recursos de hardware ou em recursos de software. 

Nesta seção, examinaremos os impasses mais de perto, veremos como eles surgem e 
estudaremos algumas maneiras de preveni-los ou evitá-los. Embora esse material seja a res- 
peito de impasses no contexto dos sistemas operacionais, eles também ocorrem em sistemas 
de banco de dados e em muitos outros contextos da ciência da computação; portanto, esse 
material pode ser aplicado a uma ampla variedade de sistemas de múltiplos processos. 


3.3.1 Recursos 


Os impasses podem ocorrer quando os processos obtêm acesso exclusivo para dispositivos, 
arquivos etc. Para tornar a discussão sobre impasses a mais genérica possível, vamos nos refe- 
rir aos objetos concedidos como recursos. Um recurso pode ser um dispositivo de hardware 
(por exemplo, uma unidade de fita) ou uma informação (por exemplo, um registro em um 
banco de dados). Um computador normalmente terá muitos recursos diferentes que podem 
ser solicitados por processos. Para alguns recursos, várias instâncias idênticas podem estar 
disponíveis, como no caso de três unidades de fita. Quando estão disponíveis cópias intercam- 
biáveis de um recurso, chamadas de recursos fungíveis”, qualquer um deles pode ser usado 


Este é um termo jurídico e financeiro. O ouro é fungível: um grama de ouro vale tanto quanto qualquer outro. 
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3.3.2 


para atender qualquer requisição de alocação deste recurso. Em resumo, um recurso é algo 
que pode ser usado por apenas um processo em dado instante. 

Existem dois tipos de recursos: preemptivo e não-preemptivo. Um recurso preemptivo 
é aquele que pode ser retirado do processo que o possui sem nenhum efeito prejudicial. A 
memória é um exemplo de recurso preemptivo. Considere, por exemplo, um sistema com 64 
MB de memória de usuário, uma impressora e dois processos de 64 MB, cada um querendo 
imprimir algo. O processo A solicita e obtém a impressora; então, ele começa a calcular os 
valores a serem impressos. Antes que tenha terminado o cálculo, ele ultrapassa seu quantum 
de tempo e é trocado ou paginado. 

Agora, o processo B é executado e tenta, sem sucesso, adquirir a impressora. Possi- 
velmente, agora temos uma situação de impasse, pois A tem a impressora, B tem a memória 
e nenhum deles pode prosseguir sem o recurso mantido pelo outro. Felizmente, é possível 
retirar a memória de B (preempção) e alocá-la para A. Agora, A pode ser executado, fazer sua 
impressão e depois liberar a impressora. Nenhum impasse ocorre. 

Um recurso não-preemptivo, em contraste, é aquele que não pode ser retirado de seu 
proprietário corrente sem fazer a computação falhar. Se um processo tiver começado a gravar 
um CD-ROM, retirar repentinamente o gravador de CD dele e passá-lo a outro processo re- 
sultará em um CD corrompido. Os gravadores de CD não são preemptivos em um momento 
arbitrário. 

Em geral, os impasses ocorrem quando temos recursos não-preemptivos. Os impasses 
em potencial que envolvem recursos preemptivos normalmente podem ser resolvidos pela 
realocação dos recursos de um processo para outro. Assim, nosso tratamento focalizará os 
recursos não-preemptivos. 

A segiiência de eventos exigida para usar um recurso aparece a seguir, de uma forma 
abstrata. 


1. Solicitar o recurso. 
2. Utilizar o recurso. 


3. Liberar o recurso. 


Se o recurso não estiver disponível ao ser solicitado, o processo solicitante será obri- 
gado a esperar. Em alguns sistemas operacionais, o processo é bloqueado automaticamente 
quando a requisição de um recurso falha e é desbloqueado quando ele se torna disponível. Em 
outros sistemas, a requisição falha e retorna um código de erro e fica por conta do processo 
que fez a chamada esperar um pouco e tentar novamente. 


Princípios do impasse 


O impasse pode ser definido formalmente como segue: 


Um conjunto de processos está em um impasse se cada processo do conjunto está 
esperando por um evento que apenas outro processo do conjunto pode causar. 


Como todos os processos estão esperando, nenhum deles jamais causará os eventos 
que poderiam liberar um dos outros membros do conjunto e todos os processos continuarão 
a esperar para sempre. Para esse modelo, supomos que os processos têm apenas uma thread 
de execução e que não existem interrupções possíveis para liberar um processo bloqueado. A 
condição de nenhuma interrupção é necessária para impedir que um processo que esteja em 
um impasse por outro motivo seja acordado por, digamos, um alarme, e então cause eventos 
que liberem outros processos no conjunto. 
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Na maioria dos casos, o evento que cada processo está esperando é a liberação de algum 
recurso correntemente pertencente a outro membro do conjunto. Em outras palavras, cada 
membro do conjunto de processos em impasse está esperando por um recurso que pertence 
a um processo em impasse. Nenhum dos processos pode ser executado, nenhum deles pode 
liberar quaisquer recursos e nenhum deles pode ser acordado. O número de processos e o 
número e o tipo de recursos alocados e solicitados não têm importância. Esse resultado vale 
para qualquer tipo de recurso, incluindo hardware e software. 


Condições de impasse 


Coffman et al. (1971) mostraram que quatro condições devem ser verdadeiras para que haja 
um impasse: 


1. Condição de exclusão mútua. Cada recurso ou está correntemente atribuído a exa- 
tamente um processo ou está disponível. 


2. Condição de posse e espera. Os processos que correntemente possuem recursos 
garantidos anteriormente podem solicitar novos recursos. 


3. Ausência de preempção. Os recursos garantidos anteriormente não podem ser re- 
tirados à força de um processo. Eles devem ser liberados explicitamente pelo pro- 
cesso que os possui. 


4. Condição de espera circular. Deve haver um encadeamento circular de dois ou 
mais processos, cada um dos quais esperando por um recurso mantido pelo próxi- 
mo membro do encadeamento. 


Essas quatro condições devem estar presentes para que um impasse ocorra. Se uma 
delas estiver ausente, não há a possibilidade de ocorrência de impasse. 

Em uma série de artigos, Levine (2003a, 2003b, 2005) mostra que existem várias situa- 
ções que também são chamadas de impasse na literatura existente e que as condições de Co- 
ffman et al.se aplicam apenas ao que deve ser corretamente chamado de impasse de recurso. 
A literatura contém exemplos de “impasse” que não satisfazem todas essas condições. Por 
exemplo, se quatro veículos chegam simultaneamente em um cruzamento e tentam obedecer 
a regra de que cada um deve ceder a vez para o veículo que está à sua direita, nenhum deles 
poderá prosseguir, mas esse não é um caso onde um processo já possui um único recurso. Em 
vez disso, esse problema é um “impasse de escalonamento”, que pode ser resolvido por uma 
decisão sobre prioridades, imposta de fora por um policial. 

Vale notar que cada condição se relaciona com uma política que um sistema pode ter 
ou não. Determinado recurso pode ser atribuído a mais de um processo simultaneamente”? 
Um processo pode possuir um recurso e solicitar outro? Pode haver preempção dos recursos? 
As esperas circulares podem existir? Veremos, posteriormente, como os impasses podem ser 
atacados tentando negar uma dessas condições. 


Modelagem do impasse 


Holt (1972) mostrou como essas quatro condições podem ser modeladas, usando grafos di- 
rígidos. Os grafos têm dois tipos de nós: processos, mostrados como círculos, e recursos, 
mostrados como quadrados. Um arco de um nó de recurso (quadrado) para um nó de processo 
(círculo) significa que o recurso foi solicitado anteriormente, foi concedido e é correntemente 
mantido por esse processo. Na Figura 3-9(a), o recurso R está correntemente atribuído ao 
processo 4. 
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(a) 


(a) (b) 


Figura 3-9 Grafos de alocação de recurso. (a) Mantendo um recurso. (b) Solicitando um 
recurso. (c) Impasse. 


Um arco de um processo para um recurso significa que o processo está correntemente 
bloqueado, esperando por esse recurso. Na Figura 3-9(b), o processo B está esperando pelo 
recurso S. Na Figura 3-9(c), vemos um impasse: o processo C está esperando pelo recurso T, 
o qual é correntemente mantido pelo processo D. O processo D não pode liberar o recurso T, 
pois está esperando pelo recurso U, mantido por C. Os dois processos vão esperar para sem- 
pre. Um ciclo no grafo significa que existe um impasse envolvendo os processos e recursos 
no ciclo (supondo que exista um único recurso de cada tipo). Nesse exemplo, o ciclo é C-T- 
D-U-C. 

Vamos ver agora como os grafos de recurso podem ser usados. Imagine que tenhamos 
três processos, 4, B, e C, e três recursos, R, S, e T. As requisições e liberações dos três proces- 
sos aparecem na Figura 3-10(a)-(c). O sistema operacional está livre para executar qualquer 
processo desbloqueado, a qualquer momento; portanto, ele poderia decidir executar A até que 
A terminasse todo o seu trabalho e, então, executar B até o fim e, finalmente, executar C. 

Essa ordem não leva a um impasse (pois não há nenhuma competição pelos recursos), 
mas também não tem nenhum paralelismo. Além de solicitar e liberar recursos, os processos 
fazem computação e operações de E/S. Quando os processos são executados em seqüência, 
não há nenhuma possibilidade de que, enquanto um processo esteja esperando por E/S, outro 
possa utilizar a CPU. Assim, a execução dos processos estritamente seqüencial pode não ser 
ótima. Por outro lado, se nenhum dos processos realiza qualquer operação de E/S, o algo- 
ritmo da tarefa mais curta primeiro é melhor do que o round-robin; portanto, sob algumas 
circunstâncias, executar todos os processos em segiiência pode ser a melhor maneira. 

Vamos supor agora que os processos façam tanto E/S como computação, de modo que o 
round-robin é um algoritmo de escalonamento razoável . As requisições por recurso poderiam 
ocorrer na ordem mostrada na Figura 3-10(d). Se essas seis requisições são executadas nessa 
ordem, os seis grafos de recurso resultantes são os que aparecem na Figura 3-10(e)-(j). Após 
a requisição 4 ter sido feita, A é bloqueado, esperando por S, como se vê na Figura 3-10(h). 
Nos dois passos seguintes, B e C também são bloqueados, em última análise levando a um 
ciclo e ao impasse da Figura 3-10(j). Desse ponto em diante, o sistema está “congelado”. 

Entretanto, conforme já mencionamos, o sistema operacional não é obrigado a executar 
os processos em nenhuma ordem especial. Em particular, se atender uma requisição específi- 
ca levar a um impasse, o sistema operacional pode simplesmente suspender o processo, sem 
atender a requisição (isto é, simplesmente não escalonar), até que seja seguro fazer isso. Na 
Figura 3-10, se o sistema operacional soubesse do impasse iminente, poderia suspender B, em 
vez de conceder S a ele. Executando apenas A e C, obteríamos as requisições e as liberações 
da Figura 3-10(k), em vez da Figura 3-10(d). Essa sequência leva aos grafos de recurso da 
Figura 3-10(1)-(q), que não levam a um impasse. 
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A B C 
Solicita R Solicita S Solicita T 
Solicita S Solicita T Solicita R 
Libera R Libera S Libera T 
Libera S Libera T Libera R 


(a) (b) (c) 


1. A solicita R 


sositar ORORO) © 

4. A solicita S 

5.B solicita T 

mea JEI R| R| 
(e) (f) (9) 


AN 
R| l E 


(i) 


1.A solicita R 

sm OOO 000 QOO 
3. A solicita S (A) (8) (B) (A) (E) 

4.C solicita R 

5. A libera R 


pista R| [R| 


(k) (1) (m) (n) 


(a) 


Figura 3-10 Um exemplo de como um impasse ocorre e como pode ser evitado. 


Após o passo (q), o processo B pode receber S, pois A terminou e C tem tudo que pre- 
cisa. Mesmo que B deva eventualmente ser bloqueado ao solicitar T, nenhum impasse pode 
ocorrer. B simplesmente esperará até que C tenha terminado. 
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Posteriormente neste capítulo, estudaremos detalhadamente um algoritmo para tomar 
decisões de alocação que não levam a um impasse. Por enquanto, o ponto a entender é que o 
grafo de recurso é uma ferramenta que nos permite ver se determinada segiiência de requi- 
sição/liberação leva a um impasse. Apenas executamos as requisições e liberações passo a 
passo e, após cada passo, verificamos o grafo para ver se contém ciclos. Se contiver, temos 
um impasse; caso contrário, não há impasse algum. Embora nosso tratamento de grafos de 
recurso tenha sido para o caso de um único recurso de cada tipo, eles também podem ser 
generalizados para tratar de vários recursos do mesmo tipo (Holt, 1972). Entretanto, Levine 
(2003a, 2003b) mostra que, com recursos fungíveis, isso pode ficar muito complicado. Se 
mesmo um único ramo do grafo não fizer parte de um ciclo; isto é, se um processo que não 
está em impasse contiver uma cópia de um dos recursos, então não poderá ocorrer impasse. 

Em geral, quatro estratégias são usadas para tratar com impasses. 


1. Apenas ignorar completamente o problema (Talvez, se você o ignorar, ele ignore 
você). 

2. Detecção e recuperação. Deixar os impasses ocorrerem, detectá-los e executar uma 
ação. 

3. Evitação dinâmica, por meio da alocação cuidadosa de recursos. 
Prevenção, pela negação estrutural de uma das quatro condições necessárias para 
causar um impasse. 


Examinaremos cada um desses métodos por sua vez, nas próximas quatro seções. 


3.3.3 O algoritmo do avestruz 


A estratégia mais simples é a do algoritmo do avestruz: enfiar a cabeça na terra e fingir que 
não existe problema algum’. Diferentes pessoas reagem a essa estratégia de maneiras muito 
diferentes. Os matemáticos a acham completamente inaceitável e dizem que os impasses 
devem ser evitados a qualquer custo. Os engenheiros perguntam com que freqüência o pro- 
blema é esperado, com que freqüência o sistema falha por outros motivos e qual é a gravidade 
do impasse. Se os impasses ocorrem, em média, uma vez a cada cinco anos, mas as falhas de 
sistema causadas por defeitos de hardware, erros de compilador e erros do sistema operacio- 
nal ocorrem uma vez por semana, a maioria dos engenheiros não desejará penalizar tanto o 
desempenho ou a conveniência para eliminar os impasses. 

Para tornar essa comparação mais específica, o UNIX (e o MINIX 3) potencialmente 
sofre com impasses que nem mesmo são detectados, sem falar nos que são desfeitos automa- 
ticamente. O número total de processos em um sistema é determinado pelo número de entra- 
das na tabela de processos. Assim, as entradas da tabela de processos são recursos finitos. Se 
uma operação fork falha porque a tabela está cheia, uma estratégia razoável para o programa 
que está executando essa operação é esperar um tempo aleatório e tentar novamente. 

Agora, suponha que um sistema MINIX 3 tenha 100 entradas de processo. Dez progra- 
mas estão em execução, cada um dos quais precisa criar 12 (sub)processos. Depois que cada 
processo criou 9 processos, os 10 processos originais e os 90 novos processos esgotaram a 
tabela. Agora, cada um dos 10 processos originais fica em um laço infinito, tentando criar 
mais processos e falhando — em um impasse. A probabilidade disso acontecer é minúscula, 
mas poderia acontecer. Devemos abandonar os processos e a chamada de fork para eliminar 
o problema? 


* Na verdade, esse folclore não tem sentido. Os avestruzes podem correr a 60 km/h e seu chute é poderoso o bastante para matar 
qualquer leão que esteja pensando em jantar uma grande galinha. 
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3.3.4 


3.3.5 


Semelhantemente, o número máximo de arquivos abertos é restrito pelo tamanho da ta- 
bela de i-nodes; portanto, um problema semelhante ocorre quando ela é preenchida. A área de 
swap no disco é outro recurso limitado. Na verdade, quase toda tabela no sistema operacional 
representa um recurso finito. Devemos abolir todas elas porque poderia acontecer de um con- 
junto de n processos exigir 1/n do total cada um e depois cada um tentar solicitar outra? 

A maioria dos sistemas operacionais, incluindo o UNIX, o MINIX 3 e o Windows, 
simplesmente ignora o problema, supondo que a maioria dos usuários preferiria um impasse 
ocasional a uma regra restringindo todos eles a um único processo, um único arquivo aberto e 
um de tudo mais. Se os impasses pudessem ser eliminados gratuitamente, não haveria muita 
discussão. O problema é que o preço é alto, principalmente em termos de impor restrições 
inconvenientes aos processos, conforme veremos em breve. Assim, estamos diante de um 
compromisso desagradável entre conveniência e correção, e de muita discussão sobre o que é 
mais importante e para quem. Sob essas condições, soluções gerais são difíceis de encontrar. 


Detecção e recuperação 


Uma segunda técnica é a detecção e recuperação. Quando essa técnica é usada, o sistema não 
faz nada, exceto monitorar as requisições e liberações de recursos. Sempre que um recurso é 
solicitado ou liberado, o grafo de recurso é atualizado e é feita uma verificação para saber se 
existem quaisquer ciclos. Se existir um ciclo, um dos processos do ciclo será eliminado. Se 
isso não acabar com o impasse, outro processo será eliminado e assim por diante, até que o 
ciclo seja quebrado. 

Um método um tanto quanto mais rudimentar é nem mesmo manter o grafo de recurso, 
mas verificar periodicamente se existem processos que foram continuamente bloqueados por 
mais de, digamos, uma hora. Tais processos são, então, eliminados. 

A detecção e recuperação é a estratégia frequentemente usada em computadores de 
grande porte, especialmente os sistemas de lote, nos quais normalmente é aceitável eliminar 
um processo e depois reiniciá-lo. Entretanto, deve-se tomar o cuidado de restaurar os estados 
originais dos arquivos modificados e desfazer todos os outros efeitos colaterais que possam 
ter ocorrido. 


Prevenção de impasses 


A terceira estratégia para o impasse é impor restrições convenientes sobre os processos para 
que os impasses sejam estruturalmente impossíveis. As quatro condições citadas por Coffman 
et al. (1971) dão um indício de algumas possíveis soluções. 

Primeiramente, vamos atacar a condição da exclusão mútua. Se nenhum recurso jamais 
fosse atribuído exclusivamente a um único processo, nunca teríamos impasses. Entretanto, é 
igualmente claro que permitir que dois processos escrevam na impressora ao mesmo tempo 
levará ao caos. Com o spool da saída da impressora, vários processos podem gerar saída ao 
mesmo tempo. Nesse modelo, o único processo que realmente solicita a impressora física é o 
daemon de impressora. Como o daemon nunca solicita quaisquer outros recursos, podemos 
eliminar o impasse para a impressora. 

Infelizmente, nem todos os recursos podem usar um mecanismo de spool (a tabela de 
processos não se presta a um spool). Além disso, a própria competição pelo espaço em disco 
para fazer spool pode levar ao impasse. O que aconteceria se dois processos preenchessem, 
cada um, metade da área de spool disponível e nenhum dos dois terminasse de gerar saída”? 
Se o daemon fosse programado para começar a imprimir, mesmo antes que toda a saída fosse 
posta no spool, a impressora poderia ficar ociosa, caso um processo de saída decidisse esperar 
várias horas, após a primeira rajada de saída. Por isso, os daemons normalmente são progra- 
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mados para imprimir somente depois que o arquivo de saída estiver completo. Neste caso, 
temos dois processos que concluíram parte da saída (mas não toda) e não podem continuar. 
Nenhum dos dois processos jamais terminará; portanto, temos um impasse no disco. 

A segunda das condições formuladas por Coffman et al. parece ligeiramente mais pro- 
missora. Se pudermos evitar que os processos que contêm recursos fiquem esperando por 
mais recursos, poderemos eliminar os impasses. Uma maneira de atingir esse objetivo é exi- 
gir que todos os processos solicitem todos os seus recursos antes de iniciar a execução. Se 
tudo estiver disponível, o processo receberá o que precisa e poderá ser executado até o fim. 
Se um ou mais recursos estiverem ocupados, nada será alocado e o processo simplesmente 
esperará. 

Um problema imediato dessa estratégia é que muitos processos só saberão de quantos 
recursos precisarão depois de terem começado a executar. Outro problema é que, com essa 
estratégia, os recursos não serão usados de forma ótima. Tome como exemplo um processo 
que lê dados de uma fita de entrada, os analisa por uma hora e, então, grava uma fita de saída 
e também envia os resultados para um plotter. Se todos os recursos precisarem ser solicitados 
antecipadamente, o processo amarrará a unidade de fita de saída e o plotter por uma hora. 

Uma maneira ligeiramente diferente de violar a condição de posse e espera é exigir que 
um processo que esteja solicitando um recurso primeiro libere temporariamente todos os re- 
cursos que possui correntemente. Então, ele tenta obter tudo o que precisa de uma só vez. 

Atacar a terceira condição (ausência de preempção) é ainda menos promissor do que 
atacar a segunda. Se um processo tiver recebido a impressora e estiver no meio da impressão 
de sua saída, retirar a impressora à força porque um plotter necessário não está disponível é, 
na melhor das hipóteses, complicado e, na pior, impossível. 

Resta apenas uma condição. A espera circular pode ser eliminada de várias maneiras. 
Uma delas é simplesmente ter uma regra dizendo que um processo receberá apenas um re- 
curso em dado momento. Se ele precisar de um segundo, deverá liberar o primeiro. Para um 
processo que precisa copiar um arquivo enorme de uma fita para uma impressora, essa restri- 
ção é inaceitável. 

Outra maneira de evitar a espera circular é fornecer uma numeração global de todos os 
recursos, como se vê na Figura 3-1 1(a). Agora, a regra é esta: os processos podem solicitar 
recursos quando precisarem, mas todas as requisições devem ser feitos em ordem numérica. 
Um processo pode solicitar primeiro o scanner e depois a unidade de fita, mas não pode soli- 
citar primeiro o plotter e depois o scanner. 


1. Fotocompositora (A) 


2. Scanner 

3. Plotter 

4. Unidade de fita 

5. Unidade de CD Rom 


(a) (b) 


Figura 3-11 (a) Recursos ordenados numericamente. (b) Um grafo de recurso. 


Com essa regra, o grafo de alocação de recurso nunca pode ter ciclos. Vamos ver porque 
isso é verdade, na Figura 3-1 1(b), para o caso de dois processos. Só podemos ter um impasse 
se À solicitar o recurso j e B solicitar o recurso i. Supondo que i e j são recursos distintos, eles 
terão números diferentes. Se i > j, então A não pode solicitar j, pois seu número é menor do 
que o daquele que já possui. Se i < j, então B não pode solicitar i, pois seu número é menor do 
que o daquele que já possui. De qualquer maneira, o impasse é impossível. 
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3.3.6 


Com vários processos, a mesma lógica se aplica. Em cada instante, um dos recursos 
atribuídos terá o número mais alto. O processo que contém esse recurso nunca solicitará um 
outro já atribuído. Ou ele terminará ou, na pior das hipóteses, solicitará recursos de numera- 
ção ainda maior, todos os quais estão disponíveis. Finalmente, ele terminará e liberará seus 
recursos. Nesse ponto, algum outro processo possuirá o recurso de numeração mais alta e 
também poderá terminar. Em resumo, existe um cenário onde todos os processos terminam; 
portanto, nenhum impasse está presente. 

Uma variação de menor interesse desse algoritmo é suprimir o requisito de que os re- 
cursos devem ser adquiridos em seqüência rigorosamente ascendente e insistir simplesmente 
em que nenhum processo solicite um recurso com numeração menor do que o que já possui. 
Se um processo inicialmente solicitar 9 e 10 e depois liberar a ambos, ele estará efetivamente 
começando tudo de novo, de modo que não há motivo para proibi-lo de, agora, solicitar o 
recurso 1. 

Embora a ordenação numérica dos recursos elimine o problema dos impasses, pode ser 
impossível encontrar uma ordem que satisfaça a todos. Quando os recursos incluem entradas 
da tabela de processos, área de spool em disco, registros de banco de dados bloqueados e ou- 
tros recursos abstratos, o número de recursos e os diferentes usos em potencial podem ser tão 
grandes que nenhuma ordem poderia funcionar. Além disso, conforme Levine (2005) aponta, 
a ordenação de recursos anula a fungibilidade — uma cópia perfeitamente boa e disponível 
de um recurso poderia ser inacessível com tal regra. 

As diversas estratégias de prevenção de impasse estão resumidas na Figura 3-12. 


Condição Estratégia 
Exclusão mútua Fazer spool de tudo 
Posse e espera Solicitar todos os recursos inicialmente 


Ausência de preempção Permitir preempção de recursos 


Espera circular Ordenar os recursos numericamente 


Figura 3-12 Resumo das estratégias de prevenção de impasse. 


Evitação de impasses 

Na Figura 3-10, vimos que os impasses foram evitados não pela imposição de regras arbi- 
trárias para os processos, mas pela análise cuidadosa de cada pedido de recurso para ver se 
ele poderia ser concedido com segurança. Surge a pergunta: existe um algoritmo que sempre 
possa evitar impasses, fazendo a escolha certa todas as vezes? A resposta é um sim categó- 
rico — podemos evitar impasses, mas somente se certas informações estiverem disponíveis 
antecipadamente. Nesta seção, examinaremos as maneiras de evitar impasses por meio da 
cuidadosa alocação de recursos. 


O algoritmo do banqueiro para um único recurso 


Um algoritmo de escalonamento que pode evitar impasses é creditado a Dijkstra (1965) e é 
conhecido como algoritmo do banqueiro. Ele é modelado da maneira como um banqueiro 
de uma pequena cidade poderia lidar com um grupo de clientes para os quais concedeu linhas 
de crédito. O banqueiro não tem necessariamente dinheiro suficiente em mãos para empres- 
tar a cada cliente a quantia total da linha de crédito de cada um ao mesmo tempo. Na Figura 
3- 13(a), vemos quatro clientes, 4, B, Ce D, cada um dos quais recebeu certo número de 
unidades de crédito (por exemplo, uma unidade vale 1K dólares). O banqueiro sabe que nem 
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todos os clientes precisarão de seu crédito máximo imediatamente; portanto, ele tem reserva- 
do apenas 10 unidades, em vez de 22, para atendê-los. Ele também acredita que cada cliente 
poderá pagar seu empréstimo logo após receber sua linha de crédito total (é uma cidade pe- 
quena); portanto, ele sabe que finalmente poderá atender a todos os pedidos. (Nessa analogia, 
os clientes são os processos, as unidades são, digamos, unidades de fita, e o banqueiro é o 
sistema operacional.) 


Disponível: 10 Disponível: 2 Disponível: 1 
(a) (b) (c) 


Figura 3-13 Três estados de alocação de recursos: (a) Seguro. (b) Seguro. (c) Inseguro. 


Cada parte da figura mostra um estado do sistema com relação à alocação de recursos; 
isto é, uma lista de clientes mostrando o dinheiro já emprestado (unidades de fita já atribuí- 
das) e o crédito máximo disponível (número máximo de unidades de fita necessárias simul- 
taneamente mais tarde). Um estado é seguro se existe uma seqüência de outros estados que 
leva todos os clientes a receberem empréstimos até seus limites de crédito (todos os processos 
recebendo todos os seus recursos e terminando). 

Os clientes tratam de seus respectivos negócios, fazendo pedidos de empréstimo de 
tempos em tempos (isto é, solicitando recursos). Em dado momento, a situação é como se 
vê na Figura 3-13(b). Esse estado é seguro porque, com duas unidades restando, o banqueiro 
pode atrasar qualquer pedido, exceto o de C, permitindo assim que C termine e libere os seus 
quatro recursos. Com quatro unidades em mãos, o banqueiro pode deixar que D ou B tenha as 
unidades necessárias e assim por diante. 

Considere o que aconteceria se um pedido de B de mais uma unidade fosse atendido na 
Figura 3-13(b). Teríamos a situação da Figura 3-13(c), que é insegura. Se todos os clientes 
repentinamente pedissem seus empréstimos máximos, o banqueiro não poderia atender ne- 
nhum deles e teríamos um impasse. Um estado inseguro não precisa levar a um impasse, pois 
um cliente talvez não precise da linha de crédito inteira disponível, mas o banqueiro não pode 
contar com esse comportamento. 

O algoritmo do banqueiro considera cada pedido quando ele ocorre e verifica se conce- 
dê-lo leva a um estado seguro. Se levar, o pedido é atendido; caso contrário, ele é adiado. Para 
ver se um estado é seguro, o banqueiro verifica se tem recursos suficientes para atender algum 
cliente. Se tiver, ele presume que esses empréstimos serão pagos e, agora, o cliente mais pró- 
ximo do limite é verificado e assim por diante. Se todos os empréstimos puderem finalmente 
ser pagos, o estado é seguro e o pedido inicial poderá ser concedido. 


Trajetórias de recursos 


O algoritmo anterior foi descrito em termos de uma única classe de recursos (por exemplo, 
apenas unidades de fita ou apenas impressoras, mas não alguns de cada tipo). Na Figura 
3-14, vemos um modelo para tratar com dois processos e dois recursos, por exemplo, uma 
impressora e um plotter. O eixo horizontal representa o número de instruções executadas pelo 
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processo A. O eixo vertical representa o número de instruções executadas pelo processo B. 
Em 1,, A solicita uma impressora; em L,, ele precisa de um plotter. A impressora e o plotter 
são liberados em 1, e 1,, respectivamente. O processo B precisa do plotter de I, até 1, e da 
impressora de 7, até 1,. 


B 


e u (Os dois processos 


terminaram) 
Impressora 


Plotter Is 


Impressora «——— 


«+» Plotter 


Figura 3-14 Duas trajetórias de recurso de processo. 


Cada ponto no diagrama representa um estado de junção dos dois processos. Inicial- 
mente, o estado está em p, com nenhum processo tendo executado qualquer instrução. Se o 
escalonador optar por executar primeiro A, chegaremos ao ponto q, no qual A realizou certo 
número de instruções, mas B não fez nenhuma. No ponto q, a trajetória se torna vertical, 
indicando que o escalonador optou por executar B. Com um único processador, todos os 
caminhos devem ser horizontais ou verticais, nunca diagonais. Além disso, o movimento é 
sempre para norte ou para leste, nunca para o sul nem para o oeste (os processos não podem 
ser executados para trás). 

Quando A cruza a linha 7, no caminho de r para s, ele solicita e recebe a impressora. 
Quando B chega ao ponto t, ele exige o plotter. 

As regiões sombreadas são particularmente interessantes. A região com linhas inclina- 
das de sudoeste para nordeste representa os dois processos obtendo a impressora. A regra de 
exclusão mútua torna impossível entrar nessa região. Analogamente, a região sombreada no 
sentido contrário representa os dois processos obtendo o plotter e é igualmente impossível. 
Sob nenhuma hipótese o sistema pode entrar nas regiões sombreadas. 

Se o sistema entrar na caixa limitada pelos lados formados por 1, até 1, e por 1, até L,, 
terminará por haver um impasse quando ele chegar à intersecção de J, e I, Nesse ponto, A 
está solicitando o plotter, B está solicitando a impressora e ambos já estão atribuídos. A caixa 
inteira é insegura e não se deve entrar nela. No ponto t, a única coisa segura a fazer é executar 
o processo A até que ele chegue a 7, Além desse ponto, qualquer trajetória até u servirá. 

O importante a ser visto aqui é que B está solicitando um recurso no ponto 1. O sistema 
deve decidir se vai concedê-lo ou não. Se a concessão for feita, o sistema entrará em uma 
região insegura e haverá um impasse. Para evitar o impasse, B deve ser suspenso até que A 
tenha solicitado e liberado o plotter. 
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O algoritmo do banqueiro para vários recursos 


Esse modelo gráfico é difícil de aplicar no caso geral de um número arbitrário de processos 
e um número arbitrário de classes de recurso, cada uma com várias instâncias (por exemplo, 
dois plotters, três unidades de fita). Entretanto, o algoritmo do banqueiro pode ser generaliza- 
do para fazer o trabalho. A Figura 3-15 mostra como ele funciona. 


Recursos atribuídos Recursos ainda necessários 


Figura 3-15 O algoritmo do banqueiro com vários recursos. 


Na Figura 3-15, vemos duas matrizes. A da esquerda mostra quanto de cada recurso 
está correntemente atribuído a cada um dos cinco processos. A matriz da direita mostra quan- 
tos recursos cada processo ainda precisa para terminar. Assim como no caso do recurso único, 
os processos devem informar suas necessidades de recurso totais antes de executar para que o 
sistema possa calcular a matriz da direita a cada instante. 

Os três vetores à direita da figura mostram os recursos existentes, E, os recursos possuí- 
dos, P, e os recursos disponíveis, 4, respectivamente. A partir de E, vemos que o sistema tem 
seis unidades de fita, três plotters, quatro impressoras e duas unidades de CD-ROM. Desses, 
cinco unidades de fita, três plotters, duas impressoras e duas unidades de CD-ROM estão 
correntemente atribuídas. Esse fato pode ser visto pela soma das quatro colunas de recurso na 
matriz da esquerda. O vetor de recursos disponíveis é simplesmente a diferença entre o que o 
sistema possui e o que está correntemente em uso. 

Agora, o algoritmo para verificar se um estado é seguro pode ser exposto. 


1. Procurar uma linha, R, cujas necessidades de recurso não atendidas sejam todas 
menores ou iguais a 4. Se tal linha não existir, o sistema finalmente terá um impas- 
se, pois nenhum processo poderá ser executado até o fim. 


2. Supor que o processo da linha escolhida solicite todos os recursos de que precisa 
(o que é garantido ser possível) e termine. Marcar esse processo como terminado e 
adicionar todos os seus recursos no vetor de 4. 


3. Repetir os passos 1 e 2 até que todos os processos sejam marcados como termina- 
dos, no caso em que o estado inicial era seguro, ou até que ocorra um impasse, no 
caso em que ele não era seguro. 


Se vários processos puderem ser escolhidos no passo 1, não importa qual deles é sele- 
cionado: o pool de recursos disponíveis fica maior ou permanece o mesmo. 

Agora, vamos voltar ao exemplo da Figura 3-15. O estado corrente é seguro. Suponha 
que agora o processo B solicite uma impressora. Esse pedido pode ser atendido, pois o estado 
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3.4 


resultante ainda é seguro (o processo D pode terminar e, então, os processos A ou E, seguidos 
pelos restantes). 

Imagine agora que, após dar a B uma das duas impressoras restantes, E queira a última 
impressora. Atender esse pedido reduziria o vetor de recursos disponíveis para (1 0 0 0), o que 
levaria a um impasse. Claramente, o pedido de E deve ser temporariamente adiado. 

O algoritmo do banqueiro foi publicado pela primeira vez por Dijkstra, em 1965. Desde 
então, quase todos os livros sobre sistemas operacionais o descrevem em detalhes. Incontá- 
veis artigos foram escritos sobre vários aspectos dele. Infelizmente, poucos autores tiveram 
a coragem de mencionar que, embora teoricamente o algoritmo seja maravilhoso, na prática 
ele é basicamente inútil, pois os processos raramente sabem antecipadamente qual será o 
máximo de recursos que precisarão. Além disso, o número de processos não é fixo, mas varia 
dinamicamente à medida que novos usuários se conectam e desconectam. Além disso, os re- 
cursos que são considerados disponíveis podem desaparecer repentinamente (unidades de fita 
podem se danificar). Assim, na prática, poucos sistemas existentes (se houver algum) utilizam 
o algoritmo do banqueiro para evitar impasses. 

Em resumo, os esquemas descritos anteriormente sob o título de “prevenção” são de- 
masiadamente restritivos e o algoritmo descrito aqui como “evitação” exige informações que 
normalmente não estão disponíveis. Se você puder pensar em um algoritmo de propósito 
geral que faça o trabalho na prática, assim como na teoria, escreva-o e envie-o para uma pu- 
blicação em ciência da computação. 

Embora a evitação e a prevenção não sejam terrivelmente promissoras no caso geral, 
para aplicações específicas são conhecidos muitos algoritmos de propósito especial excelentes. 
Como exemplo, em muitos sistemas de banco de dados, uma operação que ocorre frequiente- 
mente é o pedido de bloqueios em vários registros e, então, a atualização de todos os registros 
bloqueados. Quando vários processos estão sendo executados simultaneamente, existe o peri- 
go real de um impasse. Para eliminar esse problema, são utilizadas técnicas especiais. 

A estratégia utilizada mais frequentemente é chamada travamento em duas fases. Na 
primeira fase, o processo tenta travar todos os recursos de que precisa, um por vez. Se tiver 
êxito, ele começa a segunda fase, realizando suas atualizações e liberando as travas. Nenhum 
trabalho real é feito na primeira fase. 

Se, durante a primeira fase, for necessário algum recurso que já está travado, o processo 
apenas libera todas as suas travas e inicia toda a primeira fase novamente. De certo modo, 
essa estratégia é semelhante a pedir todos os recursos necessários antecipadamente ou pelo 
menos antes que seja feito algo irreversível. Em algumas versões do travamento em duas 
fases não há nenhuma liberação nem reinício, caso seja encontrado uma trava durante a pri- 
meira fase. Nessas versões, pode ocorrer um impasse. 

Entretanto, essa estratégia não é aplicável de maneira geral. Nos sistemas de tempo real 
e nos sistemas de controle de processos, por exemplo, não é aceitável apenas terminar um pro- 
cesso no meio do caminho porque um recurso não está disponível e iniciar tudo novamente. 
Também não é aceitável iniciar tudo, caso o processo tenha enviado ou recebido mensagens 
na rede, atualizado arquivos ou feito qualquer outra coisa que não possa ser repetido com 
segurança. O algoritmo só funciona nas situações onde o programador organizou as coisas 
com muito cuidado, para que o programa possa ser interrompido em qualquer ponto durante a 
primeira fase e reiniciado. Muitos aplicativos não podem ser estruturados dessa maneira. 


VISÃO GERAL DA E/S NO MINIX 3 


A E/S do MINIX 3 é estruturada como se vê na Figura 3-8. As quatro camadas superiores 
dessa figura correspondem à estrutura de quatro camadas do MINIX 3, mostrada na Figura 2- 
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3.4.1 


29. Nas seções a seguir, veremos brevemente cada uma das camadas, com ênfase nos drivers 
de dispositivo. O tratamento de interrupções foi abordado no Capítulo 2 e a E/S independente 
de dispositivo será discutida quando estudarmos o sistema de arquivos, no Capítulo 5. 


Rotinas de tratamento de interrupção e acesso de E/S no MINIX 3 


Muitos drivers de dispositivo iniciam algum dispositivo de E/S e depois são bloqueados, es- 
perando a chegada de uma mensagem. Normalmente, essa mensagem é gerada pela rotina de 
tratamento de interrupção do dispositivo. Outros drivers de dispositivo não iniciam nenhuma 
E/S física (por exemplo, lendo um disco em RAM e escrevendo em uma tela mapeada em 
espaço de memória), não usam interrupções e não esperam uma mensagem de um dispositivo 
de E/S. No capítulo anterior, os mecanismos do núcleo por meio dos quais as interrupções 
geram mensagens e causam trocas de tarefa foram apresentados com bastantes detalhes, e 
não falaremos mais nada sobre eles aqui. Discutiremos as interrupções e a E/S em drivers 
de dispositivo de maneira geral. Voltaremos aos detalhes quando examinarmos o código de 
vários dispositivos. 

Para dispositivos de disco, a entrada e saída geralmente é uma questão de mandar um 
dispositivo executar sua operação e então esperar até que a operação termine. A controladora 
de disco realiza a maior parte do trabalho e muito pouco é exigido da rotina de tratamento de 
interrupção. A vida seria simples se todas as interrupções pudessem ser tratadas com tanta 
facilidade. 

Entretanto, às vezes há mais coisas para a rotina de tratamento de baixo nível fazer. O 
mecanismo de passagem de mensagens tem um custo. Quando uma interrupção pode ocorrer 
frequentemente, mas o volume de E/S manipulada por interrupção é pequeno, pode ser in- 
teressante fazer a própria rotina de tratamento realizar mais trabalho e adiar o envio de uma 
mensagem para o driver até uma interrupção subseqiiente, quando houver mais trabalho para 
o driver fazer. No MINIX 3, isso não é possível para a maioria das operações de E/S, pois 
a rotina de tratamento de baixo nível no núcleo é uma rotina de propósito geral, usada por 
quase todos os dispositivos. 

No último capítulo, vimos que o relógio é uma exceção. Como é compilado com o 
núcleo, o relógio pode ter sua própria rotina de tratamento que realiza um trabalho extra. Em 
muitos tiques de relógio há muito pouco a ser feito, exceto manter o tempo. Isso é feito sem o 
envio de uma mensagem para a tarefa de relógio em si. A rotina de tratamento de interrupção 
do relógio incrementa uma variável, apropriadamente denominada de realtime, adicionando, 
às vezes, uma correção para os tiques contados durante uma chamada da BIOS. A rotina de 
tratamento efetua alguns cálculos aritméticos adicionais muito simples — ela incrementa 
contadores de tempo de usuário e de tempo para cobrança, decrementa o contador ticks left 
do processo corrente e faz um teste para ver se um temporizador expirou. Uma mensagem só 
será enviada para a tarefa de relógio se o processo corrente tiver utilizado todo o seu quantum 
ou se um temporizador tiver expirado. 

A rotina de tratamento de interrupção de relógio é única no MINIX 3, pois o relógio é 
o único dispositivo orientado por interrupções executado em espaço de núcleo. O hardware 
de relógio é parte integrante do PC — na verdade, a linha de interrupção de relógio não é 
associada a nenhum pino nos soquetes onde as controladoras de E/S podem ser conectadas 
— portanto, é impossível fazer um upgrade do relógio com substituição do hardware de reló- 
gio e um driver fornecido pelo fabricante. Então, é razoável o driver de relógio ser compilado 
no núcleo e ter acesso a qualquer variável em espaço de núcleo. Mas um objetivo de projeto 
importante do MINIX 3 é tornar desnecessário para qualquer outro driver de dispositivo ter 
esse tipo de acesso. 
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Os drivers de dispositivo executados em espaço de usuário não podem acessar a me- 
mória do núcleo ou as portas de E/S diretamente. Embora seja possível, isso violaria os prin- 
cípios de projeto do MINIX 3 para permitir que uma rotina de serviço de interrupção faça 
uma chamada remota para executar uma rotina de serviço dentro do segmento de texto de 
um processo de usuário. Isso seria ainda mais perigoso do que permitir que um processo em 
espaço de usuário chame uma função dentro do espaço de núcleo. Naquele caso, pelo menos 
teríamos certeza de que a função seria escrita por um projetista de sistema operacional com- 
petente, atento aos problemas de segurança, possivelmente alguém que tenha lido este livro. 
Mas o núcleo não deve confiar em código fornecido por um programa de usuário. 

Existem vários níveis diferentes de acesso de E/S que podem ser necessários para um 
driver de dispositivo em espaço de usuário. 


1. Um driver poderia precisar de acesso à memória fora de seu espaço de dados nor- 
mal. O driver de memória, que gerencia o disco em RAM, é um exemplo de driver 
que precisa apenas desse tipo de acesso. 


2. Um driver talvez precise ler e escrever em portas de E/S. As instruções em nível de 
máquina para essas operações estão disponíveis apenas em modo núcleo. Confor- 
me veremos em breve, o driver de disco rígido precisa desse tipo de acesso. 


3. Um driver talvez precise responder a interrupções previsíveis. Por exemplo, o dri- 
ver de disco rígido escreve comandos na controladora de disco, o que faz uma 
interrupção ocorrer quando a operação desejada termina. 


4. Um driver talvez precise responder a interrupções imprevisíveis. O driver de te- 
clado está nessa categoria. Essa poderia ser considerada uma subclasse do item 
anterior, mas a imprevisibilidade complica as coisas. 


Todos esses casos são suportados pelas chamadas de núcleo manipuladas pela tarefa de 
sistema. 

O primeiro caso, o acesso a segmentos de memória extras, tira proveito do suporte 
de hardware para segmentação fornecido pelos processadores Intel. Embora um processo 
normal tenha acesso apenas aos seus próprios segmentos de texto, dados e pilha, a tarefa de 
sistema permite que outros segmentos sejam definidos e acessados por processos em espaço 
de usuário. Assim, o driver de memória pode acessar uma região da memória reservada para 
uso como disco em RAM, assim como outras regiões destinadas a acesso especial. O driver 
de console acessa a memória em um adaptador de vídeo da mesma maneira. 

Para o segundo caso, o MINIX 3 fornece chamadas de núcleo para usar instruções de 
E/S. A tarefa de sistema realiza a E/S real em nome de um processo menos privilegiado. 
Posteriormente neste capítulo, veremos como o driver de disco rígido utiliza esse serviço. 
Daremos uma prévia aqui. Pode ser necessário que o driver de disco escreva em uma única 
porta de saída para selecionar um disco e, então, leia outra porta para verificar se o dispositivo 
está pronto. Se for esperado que a resposta normalmente seja muito rápida, poderá ser feita 
uma consulta seqiiencial. Existem chamadas de núcleo para especificar uma porta e os dados 
a serem escritos ou um local para receber os dados lidos. Isso exige que uma chamada para ler 
uma porta não cause bloqueio e, de fato, as chamadas de núcleo não causam bloqueio. 

Alguma segurança contra falhas de dispositivo é útil. Um laço de consulta segiiencial 
poderia incluir um contador que o terminasse caso o dispositivo não estivesse pronto após 
certo número de iterações. Em geral, essa não é uma boa idéia, pois o tempo de execução 
do laço dependerá da velocidade da CPU. Uma maneira de contornar isso é iniciar o conta- 
dor com um valor relacionado ao tempo da CPU, possivelmente usando uma variável global 
configurada na inicialização do sistema. Uma maneira melhor é oferecida pela biblioteca de 
sistema do MINIX 3, que fornece a função getuptime. Isso usa uma chamada de núcleo para 
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recuperar um contador de tiques de relógio, desde a inicialização do sistema, mantido pela 
tarefa de relógio. O custo de usar essa informação para monitorar o tempo gasto em um laço 
é a sobrecarga de uma chamada de núcleo adicional em cada iteração. Outra possibilidade 
é pedir para que a tarefa de sistema configure um temporizador de cão-de-guarda. Mas para 
receber uma notificação de um temporizador, é exigida uma operação receive, que causará 
bloqueio. Essa não é uma boa solução, caso se espere uma resposta rápida. 

O disco rígido também utiliza variantes das chamadas de núcleo para E/S que possibi- 
litam enviar para a tarefa de sistema uma lista de portas e dados para escrita ou variáveis a 
serem alteradas. Isso é muito útil — o driver de disco rígido que examinaremos exige a gra- 
vação de uma segiiência de valores de byte em sete portas de saída para iniciar uma operação. 
O último byte da sequência é um comando e a controladora de disco gera uma interrupção 
quando conclui um comando. Tudo isso pode ser realizado com uma única chamada de nú- 
cleo, reduzindo muito o número de mensagens necessárias. 

Isso nos leva ao terceiro item da lista: responder a uma interrupção esperada. Conforme 
mencionado na discussão sobre a tarefa de sistema, quando uma interrupção é iniciada em 
nome de um programa em espaço de usuário (usando uma chamada de núcleo sys irqctl), a 
rotina de tratamento da interrupção é sempre generic handler, uma função definida como 
parte da tarefa de sistema. Essa rotina converte a interrupção em uma mensagem de notifica- 
ção para o processo em cujo nome a interrupção foi estabelecida. Portanto, o driver de dispo- 
sitivo deve iniciar uma operação receive após a chamada de núcleo que envia o comando para 
a controladora. Quando a notificação é recebida, o driver de dispositivo pode prosseguir com 
o que deve ser feito para atender a interrupção. 

Embora, neste caso, seja esperada uma interrupção, é prudente proteger-se contra a 
possibilidade de que algo possa dar errado em algum momento. Para se preparar para a pos- 
sibilidade de que a interrupção não seja disparada, um processo pode pedir para que a tarefa 
de sistema configure um temporizador de cão de guarda. Os temporizadores de cão de guarda 
também geram mensagens de notificação e, assim, a operação receive poderia receber uma 
notificação porque uma interrupção ocorreu ou porque um temporizador expirou. Isso não é 
problema, pois, embora uma notificação não transmita muitas informações, ela sempre indica 
sua origem. Embora as duas notificações sejam geradas pela tarefa de sistema, a notificação 
de uma interrupção aparecerá como proveniente de HARDWARE e da notificação de um tem- 
porizador expirando aparecerá como proveniente de CLOCK. 

Há outro problema. Se uma interrupção for recebida adequadamente e um temporizador 
de cão de guarda tiver sido configurado, a expiração do temporizador em algum momen- 
to no futuro será detectada por outra operação receive, possivelmente no laço principal do 
driver. Uma solução é fazer uma chamada de núcleo para desativar o temporizador quando 
for recebida a notificação de HARDWARE. Como alternativa, se for provável que a próxima 
operação receive será uma em que uma mensagem de CLOCK não é esperada, tal mensagem 
poderia ser ignorada e a operação receive chamada novamente. Embora seja menos provável, 
é possível que uma operação de disco ocorra após um atraso inesperadamente longo, gerando 
a interrupção somente depois que o cão de guarda tiver atingido o tempo limite (timeout). As 
mesmas soluções se aplicam aqui. Quando um tempo limite é atingido, pode ser feita uma 
chamada de núcleo para desativar uma interrupção ou uma operação receive que não espera 
uma interrupção poderia ignorar qualquer mensagem de HARDWARE. 

Este é um bom momento para mencionar que, quando uma interrupção é ativada pela 
primeira vez, pode ser feita uma chamada de núcleo para configurar uma “política” para a 
interrupção. A política é simplesmente um flag que determina se a interrupção deve ser reati- 
vada automaticamente ou se deve permanecer desativada até que o driver de dispositivo que 
a atende faça uma chamada de núcleo para reativá-la. Para o driver de disco, pode haver um 
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volume substancial de trabalho a ser feito após uma interrupção e, assim, talvez seja melhor 
deixar a interrupção desativada até que todos os dados tenham sido copiados. 

O quarto item de nossa lista é o mais problemático. O suporte para teclado faz parte do 
driver tty, que fornece tanto saída como entrada. Além disso, vários dispositivos podem ser 
suportados. Portanto, a entrada pode ser proveniente de um teclado local, mas também pode 
vir de um usuário remoto, conectado por meio de uma linha serial ou de uma conexão de 
rede. E vários processos podem estar em execução, cada um produzindo saída para um termi- 
nal local ou remoto diferente. Quando não se sabe quando uma interrupção pode ocorrer, se 
é que vai ocorrer, você não pode apenas fazer uma chamada blogueante a receive para aceitar 
entrada de uma única fonte, caso o mesmo processo talvez precise responder a outras fontes 
de entrada e saída. 

O MINIX 3 usa várias técnicas para lidar com esse problema. A principal técnica uti- 
lizada pelo driver de terminal para tratar com entrada de teclado é tornar a resposta da inter- 
rupção a mais rápida possível, para que caracteres não sejam perdidos. O volume mínimo de 
trabalho possível é feito para armazenar caracteres provenientes do hardware de teclado em 
um buffer. As interrupções geram mensagens de notificação, as quais não bloqueiam o reme- 
tente; isso ajuda a evitar perda de entrada. Uma operação receive não-bloqueante é disponí- 
vel, embora só seja utilizada para manipular mensagens durante uma falha do sistema. Os 
temporizadores de sentinela também são usados para ativar a rotina que verifica o teclado. 


Drivers de dispositivo no MINIX 3 


Para cada classe de dispositivo de E/S presente em um sistema MINIX 3, existe um driver de 
dispositivo de E/S separado. Esses drivers são processos completos, cada um com seu pró- 
prio estado, registradores, pilha etc. Os drivers de dispositivo se comunicam com o sistema 
de arquivos usando o mecanismo de passagem de mensagens padrão utilizado por todos os 
processos do MINIX 3. Um driver de dispositivo simples pode ser escrito como um único 
arquivo-fonte. Para disco em RAM, disco rígido e disquete, existe um arquivo-fonte para 
suportar cada tipo de dispositivo, assim como um conjunto de rotinas comum em driverc e 
drvlib.c, para suportar todos os tipos de dispositivo de bloco. Essa separação das partes do 
software dependentes e independentes de hardware facilita a adaptação para uma variedade 
de configurações de hardware diferentes. Embora algum código-fonte comum seja usado, o 
driver para cada tipo de disco é executado como um processo separado, para suportar trans- 
ferências de dados rápidas e isolar os drivers uns dos outros. 

O código-fonte do driver de terminal é organizado de maneira semelhante, com o có- 
digo independente de hardware em tty.c e com o código-fonte para suportar diferentes dis- 
positivos, como consoles mapeados na memória, o teclado, linhas seriais e pseudoterminais, 
em arquivos separados. Neste caso, entretanto, um único processo suporta todos os diferentes 
tipos de dispositivo. 

Para grupos de dispositivos, como os dispositivos de disco e terminais, para os quais 
existem vários arquivos-fonte, também há arquivos de cabeçalho. Driver.h suporta todos os 
drivers de dispositivo de bloco. Tty.h fornece definições comuns para todos os dispositivos 
de terminal. 

O princípio de projeto do MINIX 3, de executar componentes do sistema operacio- 
nal como processos completamente separados em espaço de usuário, é altamente modular 
e moderadamente eficiente. Também é aí um dos poucos lugares onde o MINIX 3 difere do 
UNIX de uma maneira fundamental. No MINIX 3, um processo lê um arquivo enviando uma 
mensagem para o processo de sistema de arquivos. O sistema de arquivos, por sua vez, pode 
enviar uma mensagem para o driver de disco, pedindo para que ele leia o bloco necessário. 
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O driver de disco usa chamadas de núcleo para pedir à tarefa de sistema para que faça a E/S 
real e copie dados entre os processos. Essa segiiência (ligeiramente simplificada em relação à 
realidade) aparece na Figura 3-16(a). Fazendo essas interações por intermédio do mecanismo 
de mensagens, obrigamos as várias partes do sistema a fazer interface de maneiras padroni- 
zadas com as outras partes. 


Sistema estruturado em processos Sistema monolítico 
À 
Um processo 
Espaço de 
usuário Parte do 
espaço 
de usuário 
Y 
À Sistema de 
arquivos 
/ RA Espaço Driver de 
X hardware | i de núcleo dispositivo, 
% "a = A 
y 
1—6 são mensagens A parte do espaço de usuário 
de requisição e chama a parte do espaço de 
resposta entre quatro núcleo por meio de uma trap. 
processos O sistema de arquivos chama o 
independentes. driver de dispositivo como uma 


função. O sistema operacional 
inteiro faz parte de cada processo 


(a) (b) 


Figura 3-16 Duas maneiras de estruturar a comunicação usuário-sistema. 


No UNIX, todos os processos possuem duas partes: uma parte em espaço de usuário e 
uma parte em espaço de núcleo, como se vê na Figura 3-16(b). Quando é feita uma chamada 
de sistema, o sistema operacional troca da parte em espaço de usuário para a parte em espa- 
ço de núcleo de uma maneira um tanto mágica. Essa estrutura é um vestígio do projeto do 
MULTICS, no qual a troca era apenas uma chamada de função normal, em vez de uma trap 
seguida do salvamento do estado da parte dote usuário, como acontece no UNIX. 

No UNIX, os drivers de dispositivo são simplesmente funções do núcleo chamadas pela 
parte em espaço de núcleo do processo. Quando um driver precisa esperar por uma interrup- 
ção, ele chama uma função do núcleo que o coloca em repouso (sleep) até que alguma rotina 
de tratamento de interrupção o desperte (wakeup). Note que é o próprio processo de usuário 
que está sendo colocado em repouso aqui, pois, na realidade, as partes de núcleo e de usuário 
são divisões diferentes do mesmo processo. 

Entre os projetistas de sistema operacional, os argumentos sobre as vantagens dos sis- 
temas monolíticos, como no UNIX, versus sistemas estruturados em processos, como no 
MINIX 3, são infinitos. A estratégia do MINIX 3 é melhor estruturada (mais modular), tem 
interfaces mais limpas entre as partes e se estende facilmente para sistemas distribuídos, nos 
quais vários processos são executados em diferentes computadores. A estratégia do UNIX é 
mais eficiente, pois as chamadas de função são muito mais rápidas do que o envio de mensa- 
gens. O MINIX 3 foi dividido em muitos processos, pois acreditamos que com a disponibi- 
lidade de computadores pessoais cada vez mais poderosos, uma estrutura de software mais 
limpa compensaria o fato de tornar o sistema ligeiramente mais lento. Normalmente, a perda 
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de desempenho devida ao fato de ter a maior parte do sistema operacional executando em 
espaço de usuário está na faixa de 5-10%. Esteja avisado de que alguns projetistas de sistema 
operacional não compartilham a crença de que vale a pena sacrificar um pouco a velocidade 
para se obter um sistema mais modular e mais confiável. 

Neste capítulo, são discutidos os drivers para disco em RAM, disco rígido, relógio e 
terminal. A configuração padrão do MINIX 3 também inclui drivers para o disquete e para a 
impressora, os quais não serão discutidos em detalhes. A distribuição de software do MINIX 
3 contém o código-fonte dos drivers adicionais para linhas seriais RS$-232, CD-ROMs, vários 
adaptadores Ethernet e placas de som. Eles podem ser compilados separadamente e iniciados 
dinamicamente a qualquer momento. 

Todos esses drivers fazem interface com outras partes do sistema MINIX 3 da mesma 
maneira: mensagens de requisição são enviadas para os drivers. As mensagens contêm uma 
variedade de campos usados para conter o código da operação (por exemplo, READ ou WRI- 
TE) e seus parâmetros. Um driver tenta atender uma requisição e retorna uma mensagem de 
resposta. 

Para dispositivos de bloco, os campos das mensagens de requisição e resposta aparecem 
na Figura 3-17. A mensagem de requisição inclui o endereço de uma área de buffer conten- 
do os dados a serem transmitidos ou na qual os dados recebidos são esperados. A resposta 
inclui informações de status para que o processo solicitante possa verificar se sua requisição 
foi transmitida corretamente. Os campos para os dispositivos de caractere são basicamente 
iguais, mas podem variar ligeiramente de um driver para outro. As mensagens para o driver 
de terminal podem conter o endereço de uma estrutura de dados que especifica todos os mui- 
tos aspectos de um terminal que podem ser configurados, como os caracteres a serem usados 
para as funções de edição de linha para apagar caractere e apagar linha. 

A função de cada driver é aceitar requisições de outros processos (normalmente o sis- 
tema de arquivos) e executá-los. Todos os drivers de dispositivo de bloco foram escritos para 
receber uma mensagem, executá-la e enviar uma resposta. Dentre outras coisas, essa decisão 
significa que esses drivers são estritamente segiienciais e não contêm nenhuma multipro- 
gramação interna, para mantê-los simples. Quando uma requisição em hardware é feita, o 
driver executa uma operação receive especificando que está interessado apenas em aceitar 
mensagens de interrupção e não em novos pedidos de trabalho. Todas as novas mensagens 
de requisição ficam apenas esperando, até que o trabalho corrente tenha terminado (princípio 
do rendez-vous). O driver de terminal é ligeiramente diferente, pois um único driver atende 
vários dispositivos. Assim, é possível aceitar uma nova requisição de entrada do teclado, 
enquanto uma requisição para ler uma linha serial ainda está sendo atendida. Contudo, para 
cada dispositivo, uma requisição deve ser concluída, antes de iniciar uma nova. 

O programa principal de cada driver de dispositivo de bloco é estruturalmente o mesmo 
e está esboçado na Figura 3-18. Quando o sistema começa a ser usado, cada um dos drivers é 
iniciado individualmente, para dar a cada um deles uma chance de inicializar tabelas internas 
e estruturas semelhantes. Então, cada driver de dispositivo é bloqueado, tentando obter uma 
mensagem. Quando chega uma mensagem, a identidade do processo que fez a chamada é sal- 
va e uma função é chamada para realizar o trabalho, com uma função diferente ativada para 
cada operação disponível. Após o trabalho ter terminado, uma resposta é enviada de volta 
para o processo que fez a chamada e, então, o driver volta para o início do laço para esperar 
a próxima requisição. 

Cada uma das funções dev XXX manipula uma das operações que o driver é capaz de 
executar. É retornado um código de status dizendo o que aconteceu. O código de status, que 
é incluído na mensagem de resposta como o campo REP STATUS, é a contagem de bytes 
transferidos (zero ou um valor positivo), caso tudo tenha corrido bem, ou o número do erro 
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Requisições 

Campo Tipo Significado 

m.m type int Operação solicitada 

m.PROC NR int Processo solicitando a E/S 

m.POSITION long Posição no dispositivo 

Respostas 

Campo Tipo | Significado 
m.m type int Sempre DRIVER REPLY 
m.REP PROC NR | int O mesmo que PROC NR da requisição 
m.REP STATUS int Bytes transferidos ou código do erro 


Figura 3-17 Campos das mensagens enviadas pelo sistema de arquivos para os drivers de 
dispositivo de bloco e campos das respostas enviadas em retorno. 


(negativo), se algo deu errado. Essa contagem pode diferir do número de bytes solicitados. 
Quando o final de um arquivo é atingido, o número de bytes disponíveis pode ser menor do 
que o número solicitado. Nos terminais, no máximo uma linha é retornada (exceto no modo 
bruto), mesmo que a contagem solicitada seja maior. 


message mess; /* buffer de mensagem */ 


voidio driver) { 


while (TRUE) { 


initialize(); /* feito apenas uma vez, durante a inicialização do 
sistema. */ 
receive(ANY, &mess); /* espera uma requisição para atender */ 
caller = mess.source; /* processo de quem veio a mensagem */ 


} 
} 


switch(mess.type) { 
case READ: rcode = dev_read(&mess); break; 
case WRITE: rcode = dev_write(&mess); break; 
/* Demais casos entram aqui, incluindo OPEN, CLOSE e IOCTL */ 
default: rcode = ERROR; 
} 
mess.type = DRIVER REPLY; 
mess.status = rcode; /* código do resultado */ 
send(caller, &mess); /* retorna mensagem de resposta para o processo 
que fez a chamada */ 


Figura 3-18 Esboço da função principal de um driver de dispositivo de E/S. 
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Software de E/S independente de dispositivo no MINIX 3 


No MINIX 3, o processo do sistema de arquivos contém todo o código de E/S independente 
de dispositivo. O sistema de E/S é tão intimamente relacionado com o sistema de arquivos 
que eles foram mesclados em um único processo. As funções executadas pelo sistema de 
arquivos são as que aparecem na Figura 3-6, exceto quanto a solicitação e a liberação de 
dispositivos dedicados, que não existem no MINIX 3 conforme está atualmente configurado. 
Contudo, eles poderiam ser adicionados facilmente nos drivers de dispositivo relevantes, caso 
haja necessidade no futuro. 

Além de manipular a interface com os drivers, fazer uso de buffers e alocação de blocos, 
o sistema de arquivos também trata da proteção e do gerenciamento de i-nodes, diretórios e 
sistemas de arquivos montados. Isso será abordado em detalhes no Capítulo 5. 


Software de E/S em nível de usuário no MINIX 3 


O modelo geral esboçado anteriormente neste capítulo também se aplica aqui. Estão dispo- 
níveis funções de biblioteca para fazer chamadas de sistema e para todas as funções em C 
exigidas pelo padrão POSIX, como as funções de entrada e saída formatada, printf e scanf. 
A configuração padrão do MINIX 3 contém um único daemon de spool, Ipd, que faz spool e 
imprime os arquivos passados a ele pelo comando lp. A distribuição de software padrão do 
MINIX 3 também fornece vários daemons que suportam diversas funções de rede. A confi- 
guração do MINIX 3 descrita neste livro suporta a maior parte das operações de rede; basta 
ativar o servidor de rede e os drivers de adaptadores ethernet no momento da inicialização. 
Recompilar o driver de terminal com suporte para pseudo-terminais e linha serial adicionará 
suporte para logins a partir de terminais remotos e interligação em rede por meio de linhas 
seriais (incluindo modems). O servidor de rede executa com a mesma prioridade do geren- 
ciador de memória e do sistema de arquivos e, como eles, é executado como um processo de 
usuário. 


Tratamento de impasses no MINIX 3 


Fiel à sua herança, o MINIX 3 segue o mesmo caminho do UNIX com relação aos impas- 
ses dos tipos descritos anteriormente neste capítulo: ele simplesmente ignora o problema. 
Normalmente, o MINIX 3 não contém dispositivos de E/S dedicados, embora, se alguém 
quisesse pendurar uma unidade de fita DAT padrão em um PC e fazer driver para ela, isso não 
representaria um problema especial. Em suma, o único lugar onde podem ocorrer impasses é 
em recursos compartilhados implícitos, como as entradas da tabela de processos, entradas da 
tabela de i-nodes etc. Nenhum dos algoritmos de impasse conhecidos pode lidar com recursos 
como esses, que não são solicitados explicitamente. 

Na verdade, o que foi dito acima não é rigorosamente verdade. Aceitar o risco de que 
os processos de usuário poderiam causar impasse é uma coisa, mas dentro do próprio sistema 
operacional existem alguns lugares onde foi necessário tomar muito cuidado para evitar esses 
problemas. O principal é a interação da passagem de mensagens entre processos. Por exem- 
plo, os processos de usuário só podem usar o método de troca de mensagens sendrec; portan- 
to, um processo de usuário nunca deve ser bloqueado porque executou uma operação receive 
quando não havia nenhum processo interessado em enviar para ele (com send). Os servidores 
só utilizam send ou sendrec para se comunicarem com drivers de dispositivo e estes só usam 
send ou sendrec para se comunicarem com a tarefa de sistema na camada do núcleo. No caso 
raro onde os servidores precisam comunicar entre si, como entre o gerenciador de processos e 
o sistema de arquivos, quando eles inicializam suas respectivas partes da tabela de processos, 
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a ordem da comunicação é projetada com muito cuidado para evitar impasses. Além disso, no 
nível mais baixo do sistema de passagem de mensagens há uma verificação para garantir que, 
quando um processo está para realizar um envio, o processo de destino não esteja tentando 
fazer o mesmo. 

Além das restrições anteriores, no MINIX 3 é fornecida a primitiva de mensagem notify 
para tratar das situações em que uma mensagem precisa ser enviada na direção “contra a cor- 
rente”. Notify não causa bloqueio e, quando um destinatário não está imediatamente disponí- 
vel, as notificações são armazenadas. Quando examinarmos a implementação dos drivers de 
dispositivo do MINIX 3 neste capítulo, veremos que notify é amplamente usada. 

As travas (locks) representam outro mecanismo que pode evitar impasses. É possível 
travar dispositivos e arquivos mesmo sem suporte do sistema operacional. Um nome de ar- 
quivo pode servir como uma variável realmente global, cuja presença ou ausência pode ser 
notada por todos os outros processos. Um diretório especial, /usr/spool/locks/, normalmente 
está presente nos sistemas MINIX 3, assim como na maioria dos sistemas do tipo UNIX, 
onde os processos podem criar arquivos de travamento (lock files) para marcar os recursos 
que estão usando. O sistema de arquivos do MINIX 3 também suporta o estilo POSIX de 
consultas a arquivos de travamento. Mas nenhum desses mecanismos é obrigatório. Eles de- 
pendem do bom comportamento dos processos e não há nada para impedir que um programa 
tente usar um recurso que foi travado por outro processo. Isso não é exatamente o mesmo que 
a preempção do recurso, pois não impede que o primeiro processo tente continuar utilizando 
o recurso. Em outras palavras, não há nenhuma exclusão mútua. O resultado de tal ação por 
parte de um processo mal-comportado provavelmente será uma confusão, mas não resultará 
em nenhum impasse. 


DISPOSITIVOS DE BLOCO NO MINIX 3 


O MINIX 3 suporta vários dispositivos de bloco diferentes; portanto, começaremos discutindo 
os aspectos comuns de todos os dispositivos de bloco. Em seguida, discutiremos o disco em 
RAM, o disco rígido e o disquete. Cada um deles é interessante por um motivo diferente. O 
disco em RAM é um bom exemplo para estudar, pois ele tem todas as propriedades dos dispo- 
sitivos de bloco em geral, exceto a E/S real — pois o “disco” é na verdade apenas uma parte da 
memória. Essa simplicidade o torna um bom lugar para começar. O disco rígido mostra como 
é um driver de disco real. Poderia se esperar que o disquete fosse mais fácil de suportar do que 
o disco rígido, mas, na verdade, não é. Não vamos discutir todos os detalhes do disquete, mas 
mencionaremos várias das complicações encontradas em um driver de disquete. 

Mais adiante, após a discussão sobre os drivers de bloco, discutiremos o driver de ter- 
minal (teclado e tela), que é importante em todos os sistemas e, além disso, é um bom exem- 
plo de driver de dispositivo de caractere. 

Cada uma dessas seções descreve o hardware relevante, os princípios de software exis- 
tentes por trás do driver, uma visão geral da implementação e o código em si. Essa estrutura 
pode tornar as seções uma leitura útil, mesmo para os leitores que não estejam interessados 
nos detalhes do código em si. 


Visão geral dos drivers de dispositivos de bloco no MINIX 3 


Mencionamos anteriormente que as principais funções de todos os drivers de E/S têm uma 
estrutura semelhante. O MINIX 3 sempre tem pelo menos dois drivers de dispositivo de blo- 
co compilados no sistema: o driver de disco em RAM e um dos vários drivers de disco rígido 
possíveis ou um driver de disquete. Normalmente, existem três dispositivos de blocos presen- 
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tes: um driver de disquete, um driver de disco rígido IDE (Integrated Drive Electronics) e o 
disco em RAM. O driver de cada dispositivo de bloco é compilado independentemente, mas 
uma biblioteca comum de código-fonte é compartilhada por todos eles. 

Nas versões mais antigas do MINIX, às vezes estava presente um driver de CD-ROM 
separado e, se necessário, podia ser adicionado. Agora, os drivers de CD-ROM separados 
estão obsoletos. Eles eram necessários para suportar as interfaces patenteadas de diferentes 
fabricantes de unidade de disco, mas as unidades de CD-ROM modernas normalmente são 
conectadas na controladora IDE, embora em alguns notebooks os CD-ROMs são USB. A 
versão completa do driver de dispositivo de disco rígido do MINIX 3 inclui suporte para 
CD-ROM, mas retiramos o suporte para CD-ROM do driver descrito neste texto e listado no 
Apêndice B. 

Naturalmente, cada driver de dispositivo de bloco precisa de alguma inicialização. O 
driver de disco em RAM precisa reservar uma porção de memória, o driver de disco rígido 
precisa determinar os parâmetros do hardware de disco rígido etc. Todos os drivers de disco 
são chamados individualmente para inicialização específica do hardware. Após fazer o que 
for necessário, cada driver chama então a função que contém seu laço principal. Esse laço é 
executado eternamente; não há retorno para o processo que fez a chamada. Dentro do laço 
principal uma mensagem é recebida, é chamada uma função para executar a operação solici- 
tada pela mensagem e, então, é gerada uma mensagem de resposta. 

O laço principal comum chamado em cada processo de driver de disco é compilado 
quando drivers/libdriver/driver.c e os outros arquivos em seu diretório são compilados e, 
então, uma cópia do arquivo-objeto driver.o é ligada no arquivo executável de cada driver de 
disco. A técnica usada é fazer com que cada driver passe para o laço principal um parâmetro 
consistindo em um ponteiro para uma tabela dos endereços das funções que o driver usará 
para cada operação e, então, chamar essas funções indiretamente. 

Se os drivers fossem compilados juntos em um único arquivo executável, somente uma 
cópia do laço principal seria necessária. Na verdade, esse código foi escrito primeiro para 
uma versão anterior do MINIX, na qual todos os drivers eram compilados juntos. A ênfase no 
MINIX 3 está em tornar os componentes individuais do sistema operacional o mais indepen- 
dentes possível, mas usar código-fonte comum para programas separados ainda é uma boa 
maneira de aumentar a confiabilidade. Supondo que você faça isso corretamente uma vez, 
estará certo para todos os drivers. Ou então, um erro encontrado em um uso poderia muito 
bem passar despercebido em outros. Assim, o código-fonte compartilhado é testado mais 
completamente. 

Diversas outras funções potencialmente úteis para vários drivers de disco são definidas 
em drivers/libdriver/drvlib.c e ao ligar drvlib.o as torna disponíveis. Toda a funcionalidade 
poderia ter sido fornecida em um único arquivo, mas nem tudo é necessário para cada driver 
de disco. Por exemplo, o driver memory, que é mais simples do que os outros drivers, neces- 
sita uma ligação apenas com driver.o. O driver at wini, por sua vez, necessita de ligação com 
drivero e drvlib.o. 

A Figura 3-19 mostra um esboço do laço principal, em uma forma semelhante à da 
Figura 3-18. Instruções como 


code = (*entry points->dev read)(&mess); 


são chamadas de função indiretas. Uma função dev read diferente é chamada em cada driver, 
mesmo que cada um esteja executando um laço principal compilado a partir do mesmo arqui- 
vo-fonte. Mas algumas outras operações, como, por exemplo, close, são simples o bastante 
para que mais de um dispositivo possa chamar a mesma função. 
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message mess; /* buffer de mensagem */ 


void shared io driver(struct driver table *entry points) ( 
/* a inicialização é feita em cada driver antes de executar isso */ 
while (TRUE) ( 
receive(ANY, &mess); 
caller = mess.source; 
switch(mess.type) { 
case READ: rcode = (“entry points->dev. read)(&mess); break; 
case WRITE: rcode = (“entry points->dev write)(&mess); break; 
/* Demais casos entram aqui, incluindo OPEN, CLOSE e IOCTL */ 


default: rcode = ERROR; 
} 
mess.type = DRIVER REPLY; 
mess.status = rcode; /* código do resultado */ 


send(caller, &mess); 
} 
} 


Figura 3-19 Uma função principal de driver de E/S usando chamadas indiretas. 


Existem seis operações possíveis que podem ser solicitadas por qualquer driver de dis- 
positivo. Elas correspondem aos valores que podem ser encontrados no campo m.m_type da 
mensagem da Figura 3-17. São elas: 

OPEN 

CLOSE 

READ 

WRITE 

IOCTL 

6. SCATTERED_IO 


PA peaa Da a 


Muitas dessas operações provavelmente são conhecidas dos leitores com experiência 
em programação. No nível do driver de dispositivo, a maioria das operações é relacionada 
com chamadas de sistema de mesmo nome. Por exemplo, o significado de READ e WRITE 
deve ser bastante claro. Para cada uma dessas operações, um bloco de dados é transferido do 
dispositivo para a memória do processo que iniciou a chamada ou vice-versa. Uma operação 
READ normalmente não resulta em um retorno para o processo que fez a chamada até que 
a transferência de dados tenha terminado, mas, durante uma operação WRITE, um sistema 
operacional pode colocar os dados transferidos em um buffer para efetuar posteriormente a 
transferência real para o destino e retornar imediatamente para o processo que fez a chama- 
da. Isso está correto no que diz respeito ao processo que fez a chamada; então, ele fica livre 
para reutilizar a área de memória do qual o sistema operacional copiou os dados a serem 
escritos. OPEN e CLOSE para um dispositivo têm significados semelhantes à maneira que 
as chamadas de sistema open e close se aplicam às operações em arquivos: uma operação 
OPEN deve verificar se o dispositivo é acessível ou, se não for, retornar uma mensagem de 
erro; e uma operação CLOSE deve garantir que os dados postos no buffer, que foram escritos 
pelo processo que fez a chamada, sejam completamente transferidos para seu destino final no 
dispositivo. 

A operação JOCTL pode não ser tão familiar. Muitos dispositivos de E/S têm parâme- 
tros operacionais que devem ser examinados ocasionalmente e, talvez, alterados. As opera- 
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ções JOCTL fazem isso. Um exemplo conhecido é mudar a velocidade de transmissão ou a 
paridade de uma linha de comunicação. Para dispositivos de bloco, as operações IOCTL são 
menos comuns. Examinar ou mudar a maneira como um dispositivo de disco é particionado 
é feito com uma operação TOCTL no MINIX 3 (embora pudesse muito bem ter sido feita pela 
leitura e escrita de um bloco de dados). 

Sem dúvida, a operação SCATTERED TO é a menos conhecida delas. A não ser pelos 
dispositivos de disco excessivamente rápidos (por exemplo, disco em RAM), é difícil obter 
um desempenho de disco E/S satisfatório, caso todas as requisições de disco sejam para blo- 
cos individuais, um por vez. Uma requisição de SCATTERED TO permite que o sistema de 
arquivos faça uma requisição de leitura ou escrita de vários blocos. No caso de uma operação 
READ, os blocos adicionais podem não ter sido solicitados pelo processo em nome de quem 
a chamada é feita; o sistema operacional tenta antecipar pedidos futuros de dados. Em tal re- 
quisição, nem todas as transferências solicitadas são necessariamente cumpridas pelo driver 
de dispositivo. Cada requisição de bloco pode ser modificada por um bit de flag para dizer ao 
driver de dispositivo que ela é opcional. Com efeito, o sistema de arquivos pode dizer: “Seria 
ótimo ter todos esses dados, mas não preciso de todos eles imediatamente”. O dispositivo 
pode fazer o que for melhor para ele. O driver de disquete, por exemplo, retornará todos os 
blocos de dados que puder ler de uma única trilha, efetivamente dizendo, “Vou fornecer estes 
a você, mas demora muito para me mover para outra trilha; peça novamente mais tarde para 
receber o resto”. 

Quando dados precisam ser escritos, não há como ser opcional; toda escrita é obrigató- 
ria. Contudo, o sistema operacional pode colocar no buffer várias requisições de escrita, na 
esperança de que a escrita de vários blocos possa ser feita mais eficientemente do que tratar 
de cada requisição à medida que chegam. Em uma requisição de SCATTERED TO, seja para 
leitura ou escrita, a lista de blocos solicitados é classificada e isso torna a operação mais efi- 
ciente do que tratar das requisições aleatoriamente. Além disso, fazer apenas uma chamada 
para o driver, para transferir vários blocos, reduz o número de mensagens enviadas dentro do 
MINIX 3. 


Software comum de driver de dispositivo de bloco 


As definições necessárias para todos os drivers de dispositivo de bloco estão localizadas em 
drivers/libdriver/driver.h. O mais importante nesse arquivo é a estrutura driver, nas linhas 
10829 a 10845, que é usada por cada driver para passar uma lista dos endereços das funções 
que ele usará para executar cada parte de sua tarefa. Aqui, também está definida a estrutura 
device (linhas 10856 a 10859), que contém as informações mais importantes sobre partições, 
o endereço de base e o tamanho, em unidades de byte. Esse formato foi escolhido para que 
nenhuma conversão seja necessária ao se trabalhar com dispositivos baseados em memória, 
maximizando a velocidade de resposta. Com discos reais, existem tantos outros fatores atra- 
sando o acesso, que converter em setores não é uma inconveniência significativa. 

O código-fonte do laço principal e as funções comuns de todos os drivers de dispositivo 
de bloco estão em driver.c. Após fazer toda inicialização específica do hardware necessária, 
cada driver chama driver task, passando uma estrutura driver como argumento da chamada. 
Após obter o endereço de um buffer para usar em operações de DMA, entra-se no laço prin- 
cipal (linhas 11071 a 11120). 

Na instrução switch do laço principal, os primeiros cinco tipos de mensagem, 
DEV OPEN, DEV CLOSE, DEV IOCTL, DEV CANCEL e DEV SELECT, resultam 
em chamadas indiretas usando os endereços passados na estrutura driver. As mensagens 
DEV READ e DEV WRITE resultam em chamadas diretas para do rdwt; as mensagens 
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DEV GATHER e DEV SCATTER resultam em chamadas diretas para do vrdwt. A estru- 
tura driver é passada como argumento por todas as chamadas dentro do comando switch, 
sejam diretas ou indiretas; portanto, todas as funções chamadas podem fazer mais uso dela, 
conforme for necessário. Do rdwt e do vrdwt realizam algum processamento preliminar, 
mas então também fazem chamadas indiretas para rotinas específicas do dispositivo. 

Os outros casos, HARD INT, SYS SIG e SYN ALARM, respondem às notificações. 
Elas também resultam em chamadas indiretas, mas ao terminar, cada uma delas executa um 
comando continue. Isso faz o controle retornar para o início do laço, ignorando os passos da 
limpeza e da mensagem de resposta. 

Após fazer o que for solicitado na mensagem, algum tipo de limpeza pode ser neces- 
sário, dependendo da natureza do dispositivo. Para um disquete, por exemplo, isso poderia 
envolver o início de um temporizador para desligar o motor da unidade de disco, caso outra 
requisição não chegue logo. Uma chamada indireta também é usada para isso. Após a lim- 
peza, uma mensagem de resposta é construída e enviada para o processo que fez a chamada 
(linhas 11113 a 11119). É possível uma rotina que atende a um dos tipos de mensagem retor- 
nar o valor EDONTREPLY para suprimir a mensagem de resposta, mas nenhum dos drivers 
atuais utiliza essa opção. 

A primeira coisa que cada driver faz, após entrar no laço principal, é uma chamada 
para init buffer (linha 11126), que designa um buffer para uso em operações de DMA. Essa 
inicialização é mesmo necessária, devido a uma sutileza do hardware do IBM PC original, 
que exige que o buffer de DMA não ultrapasse o limite de 64K. Isto é, um buffer de DMA de 
1 KB pode começar em 64510, mas não em 64514, pois um buffer começando neste último 
endereço ultrapassa o limite de 64K em 65536. 

Essa regra irritante ocorre porque o IBM PC usava um chip de DMA antigo, o 8237A 
da Intel, que contém um contador de 16 bits. É necessário um contador maior, porque o DMA 
utiliza endereços absolutos e não relativos a um registrador de segmento. Nas máquinas mais 
antigas que podiam endereçar apenas 1M de memória, os 16 bits de ordem mais baixa do 
endereço de DMA eram carregados no 8237A e os 4 bits de ordem mais alta eram carregados 
em um registrador de 4 bits (latch). As máquinas mais recentes usam um latch de 8 bits e 
podem endereçar 16M. Quando o 8237A vai de OxFFFF a 0x0000, ele não gera um vai-um no 
latch, de modo que o endereço de DMA repentinamente pula 64K para baixo na memória. 

Um programa em C portável não pode especificar uma posição de memória absoluta 
para uma estrutura de dados, de modo que não há como impedir que o compilador coloque o 
buffer em um local não utilizável. A solução é alocar um array de bytes duas vezes maior do 
que o necessário em buffer (linha 11044) e reservar um ponteiro tmp buf (linha 11045) para 
usar no acesso real a esse array. Init buffer faz uma configuração experimental de tmp buf 
apontando para o início de buffer e, então, faz um teste para ver se existe espaço suficiente 
antes que o limite de 64K seja atingido. Se a configuração experimental não fornecer espaço 
suficiente, tmp buf é incrementado pelo número de bytes realmente exigidos. Assim, algum 
espaço é sempre desperdiçado em uma ou outra extremidade do espaço alocado em buffer, 
mas nunca há uma falha devido ao buffer ter caído no limite de 64K. 

Os computadores mais recentes da família IBM PC têm controladoras de DMA melho- 
res; portanto, esse código poderia ser simplificado e uma pequena quantidade de memória 
recuperada, se fosse possível garantir que a máquina de alguém fosse imune a esse problema. 
Entretanto, se você estiver considerando isso, pense a respeito de como o erro se manifestará, 
caso esteja errado. Se for desejado um buffer de DMA de 1K, a chance será de uma em 64 de 
que haverá um problema em uma máquina com o chip de DMA antigo. Sempre que o código- 
fonte do núcleo é modificado de maneira a alterar o tamanho do núcleo compilado, existe a 
mesma probabilidade de que o problema se manifeste. Provavelmente, quando a falha ocorrer 
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no mês ou ano seguinte, ela será atribuída ao código que foi modificado por último. Carac- 
terísticas inesperadas de hardware, como essa, podem causar semanas de tempo perdido, 
procurando erros excessivamente obscuros (e mais ainda, quando, como nesse caso, o manual 
de referência técnica não diz nenhuma palavra a respeito). 

Do rdwt (linha 11148) é a função seguinte em driver.c. Ela, por sua vez, chama duas 
funções dependentes de dispositivo apontadas pelos campos dr prepare e dr transfer na es- 
trutura driver. Aqui e no que se segue, usaremos a notação da linguagem C (“função pontei- 
ro) para indicar que estamos falando sobre a função apontada por função ponteiro. 

Após verificar que a contagem de bytes na requisição é um valor positivo, do rdwt 
chama (*dr prepare). Essa função inicializa, na estrutura device, a base e o tamanho do 
disco da partição ou subpartição que está sendo acessada. Para o driver de memória, que não 
suporta partições, ela apenas verifica se o número secundário do dispositivo é válido. Para o 
disco rígido, ela usa o número secundário do dispositivo para obter o tamanho da partição ou 
subpartição indicada por ele. Isso deve ter êxito, pois (*dr prepare) só falha se um dispositi- 
vo inválido for especificado em uma operação open. Em seguida, uma estrutura iovec t (que 
está definida nas linhas 2856 a 2859 em include/minix/type.h), iovecl, é inicializada. Essa 
estrutura especifica o endereço virtual e o tamanho do buffer local no qual, ou a partir do 
qual, os dados serão copiados pela tarefa de sistema. Essa é a mesma estrutura utilizada como 
elemento de um array de requisições, quando a chamada é para vários blocos. O endereço 
de uma variável e o endereço do primeiro elemento de um array do mesmo tipo de variável 
podem ser manipulados exatamente da mesma maneira. Em seguida, aparece outra chamada 
indireta, desta vez para (“dr transfer), que realiza a cópia dos dados e executa as operações 
de E/S exigidas. Todas as rotinas que tratam de transferências esperam receber um array de 
requisições. Em do rdwt, o último argumento da chamada é 1, especificando um array de um 
elemento. 

Conforme veremos na discussão sobre hardware de disco, na próxima seção, responder 
às requisições de disco na ordem em que elas são recebidas pode ser ineficiente, e essa rotina 
permite que um dispositivo em particular trate das requisições da maneira que for melhor para 
ele. O procedimento indireto mascara grande parte da possível variação no funcionamento 
dos dispositivos individuais. Para o disco em RAM, dr transfer aponta para uma rotina que 
faz uma chamada de núcleo para pedir à tarefa de sistema para que copie dados de uma parte 
da memória física para outra, caso o dispositivo secundário que esteja sendo acessado seja 
/dev/ram, /dev/mem, /dev/kmem, /dev/boot ou /dev/zero. (É claro que nenhuma cópia é exigida 
para acessar /dev/null.) Para um disco real, o código apontado por dr. transfer também pre- 
cisa solicitar uma transferência de dados à tarefa de sistema. Mas antes da operação de cópia 
(para uma leitura), ou depois dela (para uma escrita), uma chamada de núcleo deve ser feita 
para pedir à tarefa de sistema a realização da E/S real, escrevendo bytes nos registradores que 
fazem parte da controladora de disco, para selecionar o local no disco e o tamanho e a direção 
da transferência. 

Na rotina de transferência, a contagem de iov size na estrutura iovecl é modificada, 
retornando um código de erro (um número negativo) se houver um erro ou um número po- 
sitivo, indicando o número de bytes transferidos. Caso nenhum byte seja transferido, não 
se trata necessariamente de um erro; isso indica que o final do dispositivo foi atingido. Ao 
retornar para o laço principal, o código de erro, ou a contagem de bytes, é retornada no campo 
REP STATUS na mensagem de resposta de driver. task. 

A próxima função, do vrdwt (linha 11182), manipula requisições de E/S esparsas. Uma 
mensagem que solicita uma requisição de E/S esparsa utiliza o campo ADDRESS para apon- 
tar para um array de estruturas iovec t, cada uma das quais especifica o endereço de um 
buffer e o número de bytes a transferir. No MINIX 3, essa requisição só pode ser feita para 


258 


SISTEMAS OPERACIONAIS 


3.5.3 


blocos adjacentes no disco; o deslocamento inicial no dispositivo e se a operação é de leitura 
ou escrita, estão presentes na mensagem. Portanto, todas as operações em uma requisição 
serão para leitura ou para escrita e elas serão classificadas na ordem do bloco no dispositivo. 
Na linha 11198, é feita uma verificação para ver se essa chamada está sendo feita em nome de 
uma tarefa de E/S em espaço de núcleo; esse é um vestígio de uma fase inicial do desenvolvi- 
mento do MINIX 3, antes que todos os drivers de disco tivessem sido escritos para execução 
em espaço de usuário. 

Basicamente, o código dessa operação é muito parecido com o realizado por do rdwt 
para uma leitura ou da escrita simples. São feitas as mesmas chamadas indiretas para as 
rotinas dependentes de dispositivo (*dr prepare) e (*dr transfer). No laço, a ordem para 
tratar de várias requisições, é feita internamente na função apontada por (*dr transfer). O 
último argumento, neste caso, não é 1, mas o tamanho do array de elementos iovec t. Após 
o término do laço, o array de requisições é copiado de volta de onde veio. O campo io size 
de cada elemento no array mostra o número de bytes transferidos para essa requisição e, em- 
bora o total não seja passado de volta diretamente na mensagem de resposta construída por 
driver. task, o processo que fez a chamada pode extraí-lo desse array. 

As rotinas seguintes em driver.c servem para dar suporte geral das operações anterio- 
res. Uma chamada de (*dr name) pode ser usada para retornar o nome de um dispositivo. 
Para um dispositivo sem um nome específico, a função no name retorna a string “noname”. 
Alguns dispositivos podem não exigir um serviço em particular; por exemplo, um disco em 
RAM não exige que seja feito um tratamento especial em uma requisição DEV CLOSE. A 
função do nop se insere aqui, retornando vários códigos, dependendo do tipo da requisição 
feita. Funções adicionais, nop signal, nop alarm, nop prepare, nop cleanup e nop cancel, 
são rotinas fictícias semelhantes para dispositivos que não precisam desses serviços. 

Finalmente, do diocntl (linha 11216) executa requisições de DEV JOCTL para um 
dispositivo de bloco. Ocorrerá um erro se for solicitada qualquer operação DEV JOCTL que 
não seja uma leitura (DIJOCGETP) ou escrita (DIOCSETP) das informações de partição. 
Do diocntl chama a função (“dr prepare) do dispositivo para verificar se ele é válido e 
para obter um ponteiro para a estrutura device que descreve a base e o tamanho da partição 
em unidades de byte. Em uma requisição de leitura, ela chama a função (*dr geometry) do 
dispositivo para obter as últimas informações de cilindro, cabeçote e setor sobre a partição. 
Em cada caso, é feita uma chamada de núcleo sys datacopy para pedir para que a tarefa de 
sistema copie os dados entre os espaços de memória do driver e o processo solicitante. 


A biblioteca de drivers 


Os arquivos drvlib.h e drvlib.c contêm código dependente do sistema que suporta partições de 
disco em computadores compatíveis com o IBM PC. 

O particionamento permite que um único dispositivo de armazenamento seja dividido 
em vários “subdispositivos”. Ele é mais comumente usado em discos rígidos, mas o MINIX 3 
também fornece suporte para particionamento de disquetes. Alguns motivos para particionar 
um dispositivo de disco são: 


1. Em discos maiores, a capacidade, por unidade, é mais barata. Se forem usados 
dois ou mais sistemas operacionais, com sistemas de arquivos diferentes, será mais 
econômico fazer a partição de um único disco grande do que instalar vários discos 
menores para cada sistema operacional. 


2. Os sistemas operacionais podem ter limites para o tamanho máximo de dispositivo 
que conseguem manipular. A versão do MINIX 3, discutida aqui, pode manipular 
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um sistema de arquivos de 4 GB, mas as versões mais antigas estão limitadas a 256 
MB. Qualquer espaço em disco superior a isso é desperdiçado. 


3. Dois ou mais sistemas de arquivos diferentes podem ser usados por um mesmo 
sistema operacional. Por exemplo, um sistema de arquivos padrão pode ser usado 
para arquivos normais e um sistema de arquivos estruturado de forma diferente 
pode ser usado para a área de swap usado pela memória virtual. 


4. Pode ser conveniente colocar uma parte dos arquivos de um sistema em um dis- 
positivo lógico separado. Colocar o sistema de arquivos raiz do MINIX 3, em um 
dispositivo de capacidade pequena, torna fácil fazer backup e também facilita co- 
piá-lo em um disco em RAM no momento da inicialização. 


O suporte para partições de disco é específico da plataforma. Essa característica não 
está relacionada ao hardware. O suporte para partição é independente de dispositivo. Mas se 
mais de um sistema operacional for executado em um conjunto de hardware em particular, 
todos deverão concordar com um formato para a tabela de partição. Nos computadores IBM 
PC, o padrão é configurado pelo comando fdisk do MS-DOS, e outros sistemas operacionais, 
como o MINIX 3, o Windows e o Linux, usam esse formato para poderem coexistir com o 
MS-DOS. Quando o MINIX 3 é portado para outro tipo de máquina, faz sentido usar um 
formato de tabela de partição compatível com os outros sistemas operacionais usados no 
novo hardware. No MINIX-3, o suporte para partições em computadores IBM foi posto em 
drvlib.c, em vez de ser incluído em driver.c, por dois motivos. Primeiro, nem todos os tipos 
de disco suportam partições. Conforme mencionado anteriormente, o driver de memória é li- 
gado a driver.o, mas não utiliza as funções compiladas em drvlib.o. Segundo, isso torna mais 
fácil portar o MINIX 3 para um hardware diferente. É mais fácil substituir um único arquivo 
pequeno do que editar um grande, com muitas seções a serem compiladas condicionalmente 
para diferentes ambientes. 

A estrutura de dados básica herdada dos projetistas de firmware está definida em include/ 
ibm/partition.h, que é incluído por uma diretiva finclude em drvlib.h (linha 10900). Isso abran- 
ge informações sobre a geometria do cilindro/cabeçote/setor de cada partição, assim como 
códigos identificando o tipo de sistema de arquivos presente na partição e um flag indicando se 
a inicialização pode ser feita por meio dela. A maior parte dessas informações não é necessária 
para o MINIX 3, uma vez que o sistema de arquivos é verificado. 

A função partition (em drvlib.c, linha 11426) é chamada na primeira vez que um dispo- 
sitivo de bloco é aberto (chamada open). Seus argumentos incluem uma estrutura driver, para 
que ela possa chamar funções específicas do dispositivo, um número secundário de dispositi- 
vo inicial e um parâmetro indicando se o particionamento é de disquete, partição primária ou 
subpartição. Ela chama a função específica do dispositivo (“dr prepare) para verificar se o 
dispositivo é válido e para obter o endereço de base e o tamanho em uma estrutura device do 
tipo mencionado na seção anterior. Então, ela chama get part table para determinar se uma 
tabela de partição está presente e, se estiver, para ler a tabela. Se não houver nenhuma tabela 
de partição, o trabalho terminou. Caso contrário, o número secundário do dispositivo da pri- 
meira partição será calculado, usando as regras de numeração de dispositivos secundários que 
se aplique ao tipo de particionamento especificado na chamada original. No caso de partições 
primárias, a tabela de partição é classificada para que a ordem das partições seja coerente com 
aquela usada pelos outros sistemas operacionais. 

Nesse ponto, é feita outra chamada para (*dr prepare), desta vez usando o número do 
dispositivo da primeira partição recentemente calculado. Se o subdispositivo for válido, então 
é feito um laço por todas as entradas da tabela, verificando se os valores lidos da tabela no 
dispositivo não estão fora do intervalo obtido anteriormente para a base e para o tamanho do 
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dispositivo inteiro. Se houver uma discrepância, a tabela na memória será ajustada de acordo. 
Isso pode parecer paranóia, mas como as tabelas de partição podem ser escritas por diferentes 
sistemas operacionais, um programador que esteja usando outro sistema poderia ter tentado 
inteligentemente usar a tabela de partição para algo inesperado ou poderia haver lixo na tabe- 
la no disco por algum outro motivo. Confiamos mais nos números que calculamos usando o 
MINIX 3. Melhor estar seguro do que se arrepender. 

Ainda dentro do laço, para todas as partições no dispositivo, se for identificada como 
sendo do MINIX 3, partition será chamada recursivamente para reunir informações de 
subpartição. Se uma partição for identificada como estendida, a função seguinte, extpartition, 
será chamada em seu lugar. 

Extpartition (linha 11501) nada tem a ver com o MINIX 3 em si; portanto, não discuti- 
remos os detalhes. Alguns outros sistemas operacionais (por exemplo, o Windows) usam par- 
tições estendidas. Eles utilizam listas encadeadas, em vez de arrays de tamanho fixo, para 
suportar subpartições. Por simplicidade, o MINIX 3 usa o mesmo mecanismo para subpar- 
tições e para partições primárias. Entretanto, um suporte mínimo para partições estendidas 
é fornecido para comandos do MINIX 3, para ler e escrever arquivos e diretórios de outros 
sistemas operacionais. Essas operações são fáceis; seria muito mais complicado fornecer su- 
porte total para montar e usar partições estendidas da mesma maneira que as partições pri- 
márias. 

Get part table (linha 11549) chama do rdwt para obter o setor em um dispositivo (ou 
subdispositivo) onde está localizada uma tabela de partição. O argumento de deslocamento 
será zero se ela for chamada para obter uma partição primária, ou diferente de zero para uma 
subpartição. Ela verifica o número mágico (0xaa55) e retorna status verdadeiro ou falso para 
indicar se foi encontrada uma tabela de partição válida. Se for encontrada uma tabela, ela a 
copiará no endereço de tabela que foi passado como argumento. 

Finalmente, sort (linha 11582) classifica as entradas em uma tabela de partição pelo se- 
tor mais baixo. As entradas marcadas como não tendo partição são excluídas da classificação, 
por isso aparecem no final, mesmo que tenham um valor zero em seus campos de setor. A 
classificação é um simples bubble sort ; não há necessidade de usar um algoritmo extravagan- 
te para classificar uma lista de quatro itens. 


DISCOS EM RAM 


Agora, voltaremos aos drivers de dispositivo de bloco individuais e estudaremos vários deles 
com detalhes. O primeiro que veremos será o driver de memória. Ele pode ser usado para 
acessar qualquer parte da memória. Sua principal utilização é permitir que uma parte da me- 
mória seja reservada para uso como um disco normal, e também vamos nos referir a ele como 
driver de disco em RAM (ramdisk). Um disco em RAM não fornece armazenamento perma- 
nente, mas quando os arquivos tiverem sido copiados nessa área, eles poderão ser acessados 
de forma extremamente rápida. 

Um disco em RAM também é útil para a instalação inicial de um sistema operacional 
em um computador com apenas um dispositivo de armazenamento removível, seja um dis- 
quete, um CD-ROM ou algum outro dispositivo. Pondo-se o dispositivo raiz no disco em 
RAM, os dispositivos de armazenamento removíveis poderão ser montados e desmontados, 
conforme for necessário, para transferir dados para o disco rígido. Colocar o dispositivo raiz 
em um disquete tornaria impossível salvar arquivos em disquetes, pois o dispositivo raiz (o 
único disquete) não pode ser desmontado. Os discos de RAM também são usados com CD- 
ROMs live, que permitem executar um sistema operacional para testes e demonstrações, sem 
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copiar nenhum arquivo no disco rígido. Ter o dispositivo raiz no disco em RAM torna o siste- 
ma altamente flexível: qualquer combinação de disquetes ou discos rígidos pode ser montada 
nele. O MINIX 3, e muitos outros sistemas operacionais, é distribuído em CD-ROM live. 

Conforme veremos, o driver de memória suporta várias outras funções, além de um 
disco em RAM. Ele suporta acesso aleatório direto a qualquer parte da memória, byte por 
byte ou em trechos de qualquer tamanho. Usado dessa maneira, ele atua como um dispositivo 
de caractere, em vez de agir como um dispositivo de bloco. Outros dispositivos de caractere 
suportados pelo driver de memória são /dev/zero e /dev/null, também conhecidos como o 
“grande sumidouro de bits”. 


Hardware e software de disco em RAM 


A idéia existente por trás de um disco em RAM é simples. Um dispositivo de bloco é um 
meio de armazenamento com dois comandos: escrever um bloco e ler um bloco. Normalmen- 
te, esses blocos são armazenados em unidades rotativas, como disquetes ou discos rígidos. 
Um disco em RAM é mais simples. Ele usa apenas uma parte previamente alocada da me- 
mória principal para armazenar os blocos. Um disco em RAM tem a vantagem do acesso ins- 
tantâneo (nenhuma há busca nem atraso rotacional), tornando-o conveniente para armazenar 
programas ou dados frequentemente acessados. 

A propósito, é interessante mostrar sucintamente uma diferença entre os sistemas que 
suportam sistemas de arquivos montados e os que não suportam (por exemplo, o MS-DOS 
e o Windows). Nos sistemas de arquivos montados, o dispositivo raiz está sempre presente e 
em um local fixo; além disso, os sistemas de arquivos removíveis (isto é, os discos) podem 
ser montados em uma árvore de arquivos para formar um sistema de arquivos integrado. Uma 
vez que tudo esteja montado, o usuário não precisará se preocupar com o fato de saber em 
qual dispositivo um arquivo está. 

Em contraste, nos sistemas como o MS-DOS, o usuário precisa especificar a locali- 
zação de cada arquivo explicitamente, como em B: \DIRWFILE, ou usando certos padrões 
(dispositivo corrente, diretório corrente etc.). Com apenas um ou dois disquetes, essa carga é 
administrável, mas em um sistema de computador grande, com dezenas de discos, monitorar 
os dispositivos o tempo todo seria insuportável. Lembre-se de que os sistemas operacionais 
do tipo UNIX são executados em hardware que varia desde pequenas máquinas domésticas 
e de escritório até supercomputadores, como o Blue Gene/L da IBM, o computador mais rá- 
pido do mundo (quando este livro estava sendo escrito); o MS-DOS só funciona em sistemas 
pequenos. 

A Figura 3-20 mostra a idéia existente por trás de um disco em RAM. O disco em RAM 
é subdividido em n blocos, dependendo da quantidade de memória alocada para ele. Cada 
bloco tem o mesmo tamanho do bloco usado nos discos reais. Quando o driver recebe uma 
mensagem para ler ou escrever um bloco, ele apenas calcula onde o bloco solicitado está na 
memória do disco em RAM e lê ou escreve nele, em vez de ler ou escrever em um disquete ou 
em um disco rígido. Em última análise, a tarefa de sistema é chamada para realizar a transfe- 
rência. Isso é feito por phys. copy, uma função em linguagem assembly no núcleo, que copia 
no (ou do) programa de usuário na máxima velocidade de que o hardware é capaz. 

Um driver de disco em RAM pode suportar várias áreas de memória utilizadas como 
disco em RAM, cada uma delas identificada por um número secundário de dispositivo dife- 
rente. Normalmente, essas áreas são distintas, mas em algumas situações bastante específicas, 
pode ser conveniente tê-las sobrepostas, conforme veremos na próxima seção. 
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Memória principal (RAM) 


Programas 
de usuário 
Disco em 
RAM | «— Bloco de disco em RAM 1 
L As leituras e as escritas do bloco O 
em RAM utilizam esta área 
Sistema 
operacional 


Figura 3-20 Um disco em RAM. 


Visão geral do driver de disco em RAM no MINIX 3 


O driver de disco em RAM do MINIX 3 é composto, na verdade, por seis drivers intimamen- 
te relacionados. Cada mensagem para ele especifica um dispositivo secundário, como segue: 


0: /dev/ram 2: Idev/kmem 4: /dev/boot 
1: /dev/mem 3: /dev/null 5: /dev/zero 


O primeiro arquivo especial listado acima, /dev/ram, é um verdadeiro disco em RAM. 
Nem seu tamanho nem sua origem são incorporados no driver. Eles são determinados pelo 
sistema de arquivos, quando o MINIX 3 é inicializado. Se os parâmetros de inicialização 
especificarem que o sistema de arquivos raiz deve estar no disco em RAM, mas se seu tama- 
nho não for especificado, será criado um disco em RAM do mesmo tamanho do dispositivo 
de imagem do sistema de arquivos raiz. Um parâmetro de inicialização pode ser usado para 
especificar um disco em RAM maior do que o sistema de arquivos raiz ou, se a raiz não é para 
ser copiada na memória RAM, o tamanho especificado poderá ser qualquer valor que caiba 
na memória e deixe memória suficiente para a operação do sistema. Uma vez conhecido o 
tamanho, um bloco de memória, grande o bastante, é alocado e removido do pool de memória 
pelo gerenciador de processos, durante sua inicialização. Essa estratégia torna possível au- 
mentar ou reduzir a quantidade de disco em RAM presente, sem ter de recompilar o sistema 
operacional. 

Os dois dispositivos secundários seguintes são usados para ler e escrever a memória fí- 
sica e a memória do núcleo, respectivamente. Quando /dev/mem é aberto e lido, ele reproduz 
o conteúdo das posições da memória física, a partir do endereço absoluto zero (os vetores 
de interrupção de modo real). Os programas de usuário normais nunca fazem isso, mas um 
programa de sistema relacionado à depuração possivelmente poderia precisar desse recurso. 
Abrir /dev/mem e gravar nele alterará os vetores de interrupção. É desnecessário dizer que 
isso só deve ser feito com o maior cuidado e por um usuário experiente que saiba exatamente 
o que está fazendo. 

O arquivo especial /dev/kmem é como /dev/mem, exceto que o byte O desse arquivo é 
o byte O da memória de dados do núcleo, uma posição cujo endereço absoluto varia, depen- 
dendo do tamanho do segmento de texto do núcleo do MINIX 3. Ele também é usado prin- 
cipalmente para depuração e por programas muito especiais. Note que as áreas do disco em 
RAM desses dois dispositivos secundários se sobrepõem. Se você souber exatamente como o 
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núcleo está colocado na memória, poderá abrir /dev/mem, procurar o início da área de dados 
do núcleo e ver exatamente a mesma coisa que aparece no início de /dev/kmem. Mas, se você 
recompilar o núcleo, alterando seu tamanho, ou se, em uma versão subsequente do MINIX 
3, o núcleo for movido para outro lugar na memória, será necessário procurar um valor dife- 
rente em /dev/mem para ver a mesma coisa que vê agora no início de /dev/kmem. Esses dois 
arquivos especiais devem ser protegidos para impedir que alguém que não seja o superusuário 
os utilize. 

O próximo arquivo nesse grupo, /dev/null, é um arquivo especial que recebe dados e os 
joga fora. Ele é comumente usado em comandos shell, quando o programa que está sendo 
chamado gera saída que não é necessária. Por exemplo, 


a.out >/dev/null 


executa o programa a.out, mas descarta sua saída. Efetivamente, o driver de disco em RAM 
trata esse dispositivo secundário como tendo tamanho zero; portanto, nenhum dado é copiado 
nele ou dele. Se você o ler, obterá um EOF (End of File — fim de arquivo) imediato. 

Se você olhou as entradas de diretório desses arquivos em /dev/, talvez tenha notado 
que, daqueles mencionados até aqui, apenas /dev/ram é um arquivo de bloco especial. To- 
dos os outros são dispositivos de caractere. Há mais um dispositivo de bloco suportado pelo 
driver de memória. Trata-se de /dev/boot. Do ponto de vista do driver de dispositivo, esse 
é outro dispositivo de bloco implementado na memória RAM, exatamente como /dev/ram. 
Entretanto, ele é inicializado copiando um arquivo anexado na imagem de inicialização, logo 
após o init, em vez de começar como um bloco de memória vazio, como é feito para /dev/ram. 
O suporte para esse dispositivo é fornecido para uso futuro e ele não é utilizado no MINIX 3, 
conforme descrito neste texto. 

Finalmente, o último dispositivo suportado pelo driver de memória é outro arquivo de 
caractere especial, /dev/zero. Às vezes, é conveniente ter uma fonte de zeros. Escrever em 
/dev/zero é como escrever em /dev/null; ele joga os dados fora. Mas ler /dev/zero fornece a 
você zeros em qualquer quantidade desejada, seja um único caractere ou um disco cheio. 

Em nível do driver, o código para manipular /dev/ram, /dev/mem, /dev/kmem e /dev/ 
boot é idêntico. A única diferença entre eles é que cada um corresponde a uma região diferen- 
te da memória, indicada pelos arrays ram origin e ram limit, cada um indexado pelo número 
secundário do dispositivo. O sistema de arquivos gerencia os dispositivos em um nível mais 
alto. O sistema de arquivos interpreta os dispositivos como sendo de caractere ou de bloco e, 
assim, pode montar /dev/ram e /dev/boot e gerenciar diretórios e arquivos nesses dispositivos. 
Para os dispositivos definidos como dispositivos de caractere, o sistema de arquivos só pode 
ler e escrever fluxos de dados (embora um fluxo lido de /dev/null obtenha apenas EOF). 


Implementação do driver de disco em RAM no MINIX 3 


Assim como nos outros drivers de disco, o laço principal do driver de disco em RAM está no 
arquivo driver.c. O suporte específico dos dispositivos de memória está em memory.c (linha 
10800). Quando o driver de memória é compilado, o arquivo-objeto drivers/libdriver/drivero, 
produzido pela compilação de drivers/libdriver/driver.c, é ligado ao arquivo-objeto drivers/ 
memory/memory.o, resultado da compilação de drivers/memory/memory.c. 

Vale a pena considerar por um momento como o laço principal é feito. A declaração da 
estrutura driver em driver.h (linhas 10829 a 10845) define uma estrutura de dados, mas não 
cria a estrutura. A declaração de m dtab, nas linhas 11645 a 11660, cria uma instância dela, 
com cada parte da estrutura inicializada com um ponteiro para uma função. Algumas dessas 
funções possuem um código genérico vindo da compulação de driver.c; por exemplo, todas 
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as funções nop. Outras funções são provenientes da compilação de memory.c; por exemplo, 
m do open. Note que, para o driver de memória, sete das entradas são rotinas que pouco ou 
nada fazem, e as duas últimas são definidas como NULL (o que significa que essas funções 
nunca serão chamadas; não há nem mesmo necessidade de uma função do nop). Tudo isso é 
um indício claro de que a operação de um disco em RAM não é terrivelmente complicada. 

O dispositivo de memória também não exige a definição de um grande número de es- 
truturas de dados. O array m geom[NR DEVS] (linha 11627) contém o valor da base e o 
tamanho, em bytes, de cada um dos seis dispositivos de memória como valores inteiros de 64 
bits, sem sinal; portanto, não há o perigo imediato de o MINIX 3 não conseguir ter um disco 
em RAM grande o suficiente. A linha seguinte define uma estrutura interessante, que não será 
vista em outros drivers. M seg/[NR DEVS] é, aparentemente, apenas um array de inteiros, 
mas esses valores inteiros são índices que permitem encontrar descritores de segmento. O 
driver de dispositivo de memória é especial entre os processos em espaço de usuário, pois 
tem a capacidade de acessar regiões de memória fora dos segmentos de texto, dados e pilha 
que todo processo possui. Esse array contém informações que permitem acessar as regiões de 
memória adicionais designadas. A variável m device contém apenas o índice nesses arrays 
do dispositivo secundário correntemente ativo. 

Para usar /dev/ram como dispositivo raiz, o driver de memória deve ser configurado 
logo durante a inicialização do MINIX 3. As estruturas kinfo e machine, que são definidas em 
seguida, contém os dados recuperados do núcleo durante a inicialização, que são necessários 
para configurar o driver de memória. 

Uma outra estrutura de dados é definida antes que o código executável comece. Trata-se 
de dev zero, um array de 1024 bytes, usado para fornecer dados quando uma chamada de 
read é feita para /dev/zero. 

A função principal main (linha 11672) chama uma outra função para fazer uma iniciali- 
zação local. Depois disso, ela desvia para o laço principal, o qual obtém mensagens, despacha 
para as funções apropriadas e envia as respostas. Não há nenhum retorno para main. 

A próxima função, m name, é simples. Quando chamada, ela retorna a string “me- 
mory”. 

Em uma operação de leitura ou escrita, o laço principal faz três chamadas: uma para 
preparar um dispositivo, uma para realizar a transferência de dados real e uma para fazer a 
limpeza. Para um dispositivo de memória, m_prepare é a primeira delas. Ela verifica se foi 
solicitado um dispositivo secundário válido e, então, retorna o endereço da estrutura que con- 
tém o endereço de base e o tamanho da área da memória RAM solicitada. A segunda chamada 
é para m_transfer (linha 11706). Essa função faz todo o trabalho. Como vimos em driver.c, 
todas as chamadas para ler ou escrever dados são transformadas para ler ou escrever vários 
blocos de dados adjacentes—se for necessário apenas um bloco, a requisição será passada 
como uma solicitação de vários blocos com uma contagem igual a um. Portanto, apenas dois 
tipos de requisições de transferência são passados para o driver, DEV_GATHER, solicitando 
a leitura de um ou mais blocos, e DEV_SCATTER, para escrever um ou mais blocos. Assim, 
após obter o número secundário do dispositivo, m_transfer entra em um laço, repetido pelo 
número de transferências solicitadas. Dentro do laço existe um comando switch para o tipo de 
dispositivo. 

O primeiro caso é para /dev/null, e a ação é retornar imediatamente de uma requisição 
DEV_GATHER ou DEV_SCATTER para o final do comando switch. Isso é assim para que o 
número de bytes transferidos (embora esse número seja zero para /dev/null) possa ser retor- 
nado, como aconteceria para qualquer operação write. 

Para todos os tipos de dispositivo que se referem às posições reais na memória, a 
ação é semelhante. O deslocamento solicitado é verificado em relação ao tamanho do dis- 
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positivo para determinar se a requisição está dentro dos limites da memória alocada para o 
dispositivo. Então, é feita uma chamada de núcleo para copiar dados na memória (ou dela) 
do processo que fez a chamada. Contudo, há dois trechos de código que fazem isso. Para 
/dev/ram, /dev/kmem e /dev/boot, são usados endereços virtuais, os quais exigem recuperar 
o endereço de segmento da região de memória a ser acessada a partir do array m seg e, en- 
tão, fazer uma chamada de núcleo sys vircopy (linhas 11640 a 11652). Para /dev/memory, é 
usado um endereço físico e a chamada é para sys physcopy. 

A operação restante é uma leitura ou escrita em /dev/zero. Para leitura, os dados são 
extraídos do array dev zero, mencionado anteriormente. Você poderia perguntar: “por que 
não apenas gerar valores zero, conforme for necessário, em vez de copiar de um buffer cheio 
deles?” Como a cópia dos dados em seu destino precisa ser feita por uma chamada de nú- 
cleo, tal método exigiria uma cópia ineficiente de bytes do driver de memória para a tarefa 
de sistema ou construir código para gerar zeros na tarefa de sistema. Esta última estratégia 
aumentaria a complexidade do código em espaço de núcleo, algo que gostaríamos de evitar 
no MINIX 3. 

Um dispositivo de memória não precisa de um terceiro passo para concluir uma operação 
de leitura ou escrita e a entrada correspondente em m dtab é uma chamada para nop finish. 

A abertura de um dispositivo de memória é feita por m do open (linha 11801). A tarefa 
é executada chamando-se m prepare para verificar se está sendo referenciado um dispositivo 
válido. Mais interessante do que o código existente é um comentário sobre ele que era encon- 
trado aqui nas versões mais antigas do MINIX. Anteriormente, havia um truque escondido. 
Uma chamada por parte de um processo de usuário para abrir /dev/mem ou /dev/kmem tam- 
bém conferia, por mágica, a esse processo, a capacidade de executar instruções que acessam 
portas de E/S. As CPUs da classe Pentium implementam quatro níveis de privilégio e os pro- 
cessos de usuário normalmente são executados no nível menos privilegiado. A CPU gera uma 
exceção de proteção geral, quando um processo tenta executar uma instrução não permitida 
por seu nível de privilégio. Fornecer uma maneira de contornar isso foi considerado seguro, 
pois os dispositivos de memória só podiam ser acessados com privilégios de superusuário 
(root). Em todo caso, esse “recurso” possivelmente arriscado está ausente no MINIX 3, pois 
agora estão disponíveis chamadas de núcleo que permitem o acesso de E/S por meio da tarefa 
de sistema. O comentário permanece para mostrar que, se o MINIX 3 for portado para um 
hardware que utilize E/S mapeada em memória, talvez esse recurso precise ser reintroduzido. 
A função para fazer isso, enable iop, permanece no código do núcleo para mostrar como 
pode ser feito, embora agora ele seja sem uso. 

A próxima função, m init (linha 11817), é chamada apenas uma vez, quando mem. task 
é executada pela primeira vez. Essa rotina usa várias chamadas de núcleo e vale a pena estudá- 
la para ver como os drivers do MINIX 3 interagem com o espaço de núcleo usando serviços da 
tarefa de sistema. Primeiramente, é feita uma chamada de núcleo sys getkinfo para obter uma 
cópia dos dados kinfo do núcleo. A partir desses dados, ela copia o endereço de base e o tama- 
nho de /dev/kmem nos campos correspondentes da estrutura de dados m geom. Uma chamada 
de núcleo diferente, sys segctl, converte o endereço físico e o tamanho de /dev/kmem nas 
informações de descritor de segmento necessárias para tratar a memória do núcleo como um 
espaço de memória virtual. Se a imagem de um dispositivo de inicialização tiver sido compila- 
da na imagem de inicialização do sistema, o campo do endereço de base de /dev/boot será di- 
ferente de zero. Se assim for, então as informações para acessar a região de memória para esse 
dispositivo serão configuradas exatamente da mesma maneira como foi feito para /dev/kmem. 
Em seguida, o array usado para fornecer dados quando /dev/zero é acessado, é explicitamente 
preenchido com zeros. Isso provavelmente é desnecessário; supõe-se que os compiladores C 
inicializem as variáveis estáticas recentemente criadas com zero. 
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Finalmente, m. init utiliza uma chamada de núcleo sys getmachine para obter outro 
conjunto de dados do núcleo, a estrutura machine que sinaliza várias alternativas de hardware 
possíveis. Neste caso, a informação necessária é se a CPU é capaz de operar no modo prote- 
gido ou não. Com base nessa informação, o tamanho de /dev/mem é configurado como 1 MB 
ou como 4 GB - 1, dependendo de o MINIX 3 estar sendo executado no modo 8088 ou 80386. 
Esses tamanhos são os máximos suportados pelo MINIX 3 e não têm nada a ver com a quan- 
tidade de memória RAM instalada na máquina. Apenas o tamanho do dispositivo é definido; 
confia-se no compilador C para atribuir o endereço de base corretamente como zero. Além 
disso, como /dev/mem é acessado como memória física (não virtual), não há necessidade de 
fazer uma chamada de núcleo sys segctl para inicializar um descritor de segmento. 

Antes de deixarmos m. init, devemos mencionar outra chamada de núcleo usada aqui, 
embora não seja óbvia no código. Muitas ações executadas durante a inicialização do dri- 
ver de memória são fundamentais para o funcionamento correto do MINIX 3 e, assim, são 
feitos vários testes e, caso um teste falhe, panic é chamada. Neste caso, panic é uma rotina 
de biblioteca que, em última análise, resulta em uma chamada de núcleo sys exit. O núcleo, 
o gerenciador de processos (conforme veremos) e o sistema de arquivos têm suas próprias 
rotinas panic. A rotina de biblioteca é fornecida para drivers de dispositivo e para outros 
componentes menores do sistema. 

Surpreendentemente, a função que acabamos de examinar, m init, não inicializa o 
dispositivo de memória /dev/ram. Isso é feito na função seguinte, m ioctl (linha 11863). 
Na verdade, existe apenas uma operação ioctl definida para o disco em RAM; trata-se de 
MIOCRAMSIZE, que é usada pelo sistema de arquivos para configurar o tamanho do disco 
em RAM. Grande parte da tarefa é feita sem exigir nenhum serviço do núcleo. A chamada 
para allocmem, na linha 11887, é uma chamada de sistema, mas não uma chamada de nú- 
cleo. Ela é manipulada pelo gerenciador de processos, o qual mantém todas as informações 
necessárias para encontrar uma região de memória disponível. Entretanto, no final, uma 
chamada de núcleo é necessária. Na linha 11894, é feita uma chamada de sys segctl para 
converter o endereço físico e o tamanho retornados por allocmem em informações de seg- 
mento necessárias para acesso futuros. 

A última função definida em memory.c é m geometry. Trata-se de uma malandragem. 
Obviamente, cilindros, cabeçotes e setores são irrelevantes no endereçamento de memória 
RAM, mas se for feito uma requisição com tais informações para um dispositivo de memória, 
essa função fingirá que ela tem 64 cabeçotes e 32 setores por trilha e calculará, a partir do 
tamanho, quantos cilindros existem. 


DISCOS 


Todos os computadores modernos, exceto os embarcados, possuem unidades de disco. Por 
isso, as estudaremos agora, começando com o hardware e, depois, falaremos algumas gene- 
ralidades sobre o software de disco. Depois disso, nos aprofundaremos na maneira como o 
MINIX 3 controla seus discos. 


Hardware de disco 


Todos os discos reais são organizados em cilindros, cada um contendo tantas trilhas quantos 
forem os cabeçotes empilhados verticalmente. As trilhas são divididas em setores, com o 
número de setores em torno da circunferência sendo, normalmente, de 8 a 32 nos disquetes 
e até várias centenas em alguns discos rígidos. Os projetos mais simples têm o mesmo nú- 
mero de setores em cada trilha. Todos os setores contêm o mesmo número de bytes, embora, 
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pensando-se um pouco, seja evidente que os setores próximos ao anel externo do disco são 
fisicamente maiores do que os que estão próximos do eixo. Entretanto, o tempo para ler ou 
escrever em cada setor será o mesmo. A densidade dos dados, obviamente, é mais alta nos 
cilindros mais internos e alguns projetos de disco exigem uma mudança na unidade de disco 
corrente para os cabeçotes de leitura e escrita das trilhas internas. Isso é manipulado pelo 
hardware da controladora de disco e não é visível para o usuário (nem para o desenvolvedor 
de um sistema operacional). 

A diferença na densidade dos dados entre as trilhas internas e externas significa um 
sacrifício na capacidade e existem sistemas mais sofisticados. Foram experimentados pro- 
jetos de disquete que giram em velocidades mais altas quando os cabeçotes estão sobre 
as trilhas externas. Isso permite a existência de mais setores nessas trilhas, aumentando a 
capacidade do disco. Contudo, esses discos não são suportados por nenhum sistema para o 
qual o MINIX 3 está correntemente disponível. As grandes unidades de disco rígido moder- 
nas também têm mais setores por trilha nas trilhas externas do que nas internas. Entretanto, 
como ocorre nas unidades de disco IDE (Integrated Drive Electronics), o sofisticado pro- 
cessamento realizado por circuitos eletrônicos internos a unidade mascara esses detalhes. 
Para o sistema operacional, elas parecem ter uma geometria simples, com o mesmo número 
de setores em cada trilha. 

Os circuitos eletrônicos da unidade de disco e da controladora são tão importantes 
quanto o hardware mecânico. O principal elemento da controladora de disco é um circui- 
to integrado especializado — na verdade, um pequeno microprocessador. Antigamente, isso 
ficaria em uma placa ligada ao barramento de interconexão de periféricos do computador, 
mas nos sistemas modernos a controladora de disco fica na própria placa-mãe. Para um disco 
rígido moderno, esse circuito da controladora de disco pode ser mais simples do que para 
um disquete, pois uma unidade de disco rígido tem uma controladora eletrônica poderosa 
integrada na própria unidade. 

Um recurso de hardware que tem importantes implicações para o driver de disco é a 
possibilidade de uma controladora fazer buscas em duas ou mais unidades de disco ao mesmo 
tempo. Isso é conhecido como busca sobreposta (overlapped seeks). Enquanto a controla- 
dora e o software estão esperando que uma busca termine em uma unidade de disco, a con- 
troladora pode iniciar uma busca em outra unidade de disco. Muitas controladoras também 
podem ler ou escrever em uma unidade de disco, enquanto fazem uma busca em uma ou mais 
unidades de disco, mas uma controladora de disquete não pode ler nem escrever em duas 
unidades de disco ao mesmo tempo. (Uma leitura ou escrita exige que a controladora transfira 
bits em um intervalo de tempo da ordem de microssegundos; portanto, grande parte de seu 
poder de computação é dedicada a esta tarefa). A situação é diferente para discos rígidos com 
controladoras integradas e um sistema com mais de uma dessas unidades é capaz de operar 
simultaneamente, pelo menos com relação à transferência entre o disco e a memória do buffer 
da controladora. Entretanto, apenas uma transferência entre a controladora e a memória do 
sistema é possível por vez. A capacidade de executar duas ou mais operações ao mesmo tem- 
po pode reduzir consideravelmente o tempo de acesso médio. 

Algo de que se deve estar ciente ao examinar as especificações dos discos rígidos mo- 
dernos é que a geometria mencionada e usada pelo software do driver é quase sempre di- 
ferente do formato físico. Na verdade, se você examinar os “parâmetros de configuração 
recomendados” de um disco rígido grande, provavelmente os encontrará especificados como 
16383 cilindros, 16 cabeçotes e 63 setores por trilha, independentemente do tamanho do dis- 
co. Esses números correspondem a um tamanho de disco de 8 GB, mas são usados para todos 
os discos, com esse tamanho ou maiores. Os projetistas da ROM BIOS original do IBM PC 
dedicaram um campo de 6 bits para a contagem de setor, 4 bits para especificar o cabeçote e 
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14 bits para selecionar um cilindro. Com setores de 512 bytes, isso significa 8 GB. Portanto, 
se você tentar instalar uma unidade de disco rígido grande em um computador muito antigo, 
poderá ver que só será possível acessar 8 GB, mesmo tendo um disco muito maior. A maneira 
normal de contornar essa limitação é usar endereçamento de bloco lógico, no qual os seto- 
res do disco são simplesmente numerados em seqüência, a partir de zero, sem considerar a 
geometria do disco. 

De qualquer modo, a geometria de um disco moderno é uma ficção. Em um disco mo- 
derno, a superfície é dividida em 20 ou mais zonas. As zonas mais próximas ao centro do disco 
têm menos setores por trilha do que as zonas mais próximas à periferia. Assim, os setores têm 
aproximadamente o mesmo comprimento físico, não importa onde estejam localizados no dis- 
co, fazendo uso mais eficiente da superfície do disco. Internamente, a controladora integrada 
endereça o disco calculando a zona, o cilindro, o cabeçote e o setor. Mas isso nunca é visível 
para o usuário e os detalhes raramente são encontrados nas especificações publicadas. A ques- 
tão é que não há porque usar endereçamento de cilindro, cabeçote e setor de um disco, a não 
ser que você esteja trabalhando com um computador muito antigo, que não suporte endereça- 
mento de bloco lógico. Além disso, não faz sentido comprar uma nova unidade de disco de 400 
GB para um PC-XT adquirido em 1983; você não poderá usar mais do que 8 GB dela. 

Este é um bom lugar para mencionar um ponto confuso sobre as especificações da ca- 
pacidade do disco. Os profissionais da computação estão acostumados a usar potências de 2 
— um quilobyte (KB) vale 2º = 1024 bytes, um megabyte (MB) vale 2” = 1024º bytes etc. 
— para expressar o tamanho dos dispositivos de memória. Então, um gigabyte (GB) deveria 
ser 1024 ou 2º bytes. Entretanto, os fabricantes de disco adotaram o hábito de usar o termo 
“gigabyte” como o significado de 10,0 que (no papel) aumenta instantaneamente o tamanho 
de seus produtos. Assim, o limite de 8 GB mencionado anteriormente é um disco de 8,4 GB 
no jargão do vendedor de disco. Recentemente, houve um movimento no sentido de usar o 
termo gibibyte (GiB) com o significado de 2%. Entretanto, neste texto, os autores, fazendo pé- 
firme e em protesto contra a agressão à tradição para propósitos de propaganda, continuarão a 
usar termos como megabyte e gigabyte com o significado que eles sempre tiveram. 


RAID 


Embora os discos modernos sejam muito mais rápidos do que os antigos, as melhorias no de- 
sempenho da CPU têm superado em muito as melhorias dos discos. Com o passar dos anos, 
várias pessoas perceberam que E/S de disco paralela poderia ser útil. Assim, surgiu uma nova 
classe de dispositivo de E/S chamada RAID, acrônimo de Redundant Array of Independent 
Disks. Na verdade, os projetistas do RAID (em Berkeley) originalmente usaram o acrônimo 
RAID com o significado de Redundant Array of Inexpensive Disks (conjunto redundante de 
discos baratos), para contrastar esse projeto com um SLED (Single Large Expensive Disk 
— disco único grande e caro). Entretanto, quando o RAID se tornou popular comercialmente, 
os fabricantes de disco mudaram o significado do acrônimo porque era difícil vender um pro- 
duto caro, cujo nome significava “barato”. A idéia básica existente por trás do RAID é instalar 
um conjunto de discos próximo ao computador, normalmente um servidor, e substituir a placa 
controladora de disco por uma controladora RAID, copiar os dados para o RAID e, então, 
continuar com a operação normal. 

Os discos independentes podem ser usados em conjunto de diversas maneiras. Não 
temos tempo para uma descrição exaustiva de todas elas e o MINIX 3 não suporta RAID (ain- 
da), mas uma introdução sobre sistemas operacionais deve pelo menos mencionar algumas 
das possibilidades. O RAID pode ser usado tanto para acelerar o acesso ao disco como para 
tornar os dados mais seguros. 
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Considere, por exemplo, um RAID muito simples, de duas unidades de disco. Quando 
vários setores de dados precisam ser escritos, a controladora RAID envia os setores 0, 2, 4 
etc. para a primeira unidade de disco e os setores 1, 3, 5 etc. para a segunda. A controladora 
divide os dados e os dois discos são acessados simultaneamente, duplicando a velocidade de 
escrita. Na leitura, as duas unidades de disco são lidas simultaneamente, mas a controladora 
monta os dados novamente na ordem correta e, para o restante do sistema, parece simples- 
mente que a velocidade de leitura é duas vezes maior. Essa técnica é chamada de stripping. 
Este é um exemplo simples de RAID nível 0. Na prática, seriam usadas quatro ou mais uni- 
dades de disco. Isso funciona melhor quando os dados são normalmente lidos ou escritos em 
grandes blocos. Obviamente, não haverá nenhum ganho se uma requisição típica de acesso ao 
disco for um único setor por vez. 

O exemplo anterior mostra como várias unidades de disco podem aumentar a veloci- 
dade. E quanto à confiabilidade? O RAID nível 1 funciona como o RAID nível 0, exceto que 
os dados são duplicados. Novamente, um conjunto muito simples de duas unidades de disco 
poderia ser usado e todos os dados poderiam ser escritos em ambas. Isso não produz nenhum 
aumento de velocidade, mas há uma redundância de 100%. Se um erro for detectado durante 
a leitura, não haverá necessidade de tentar novamente, caso a outra unidade de disco leia 
os dados corretamente. A controladora precisa apenas garantir que os dados corretos sejam 
passados para o sistema. Entretanto, provavelmente não seria uma boa idéia deixar de fazer 
as novas tentativas, caso erros fossem detectados durante a escrita. E se os erros ocorrem com 
frequência suficiente provavelmente é hora de chegar à conclusão de que uma falha completa 
é iminente. Normalmente, as unidades de disco usadas para RAIDs são do tipo hot-swap, 
significando que elas podem ser substituídas sem desligar o sistema. 

Conjuntos mais complexos, de vários discos, podem aumentar tanto a velocidade como 
a confiabilidade. Considere, por exemplo, um conjunto de 7 discos. Os bytes poderiam ser 
divididos em trechos de 4 bits, com cada bit sendo escrito em uma das quatro unidades de 
disco e com as outras três unidades armazenando um código de correção de erro de três bits. 
Se uma unidade de disco estragar e precisar ser substituída automaticamente por uma nova, 
sua ausência será equivalente a um bit danificado, e com a redundância oferecida pelo código 
de correção de erros, o sistema poderá continuar funcionando enquanto a manutenção é feita. 
Pelo custo de sete unidades de disco, você obtém um desempenho confiável e quatro vezes 
mais rápido do que uma unidade de disco e sem nenhuma paralisação de funcionamento. 


Software de disco 


Nesta seção, veremos alguns problemas relacionados aos drivers de disco em geral. Primei- 
ramente, considere quanto tempo demora para ler ou escrever um bloco de disco. O tempo 
exigido é determinado por três fatores: 


1. O tempo de busca (seek time): o tempo necessário para mover o braço para o cilin- 
dro correto 


2. O atraso rotacional (rotational delay): o tempo necessário para o setor correto girar 
sob o cabeçote 


3. O tempo de transferência de dados real (data transfer time) 


Para a maioria dos discos, o tempo de busca predomina sobre os outros dois; portanto, 
reduzir o tempo de busca médio pode melhorar substancialmente o desempenho do sistema. 

Os dispositivos de disco são propensos a erros. Algum tipo de verificação de erro, uma 
soma de verificação ou uma verificação de redundância cíclica, é sempre escrito junto com os 
dados em cada setor de um disco. Até os endereços de setor gravados quando o disco é forma- 
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tado têm verificação de dados. Normalmente, o hardware da controladora de disquete pode 
informar quando um erro é detectado, mas o software deve então decidir o que fazer com ele. 
As controladoras de disco rígido frequentemente assumem a maior parte dessa carga. 

Particularmente no caso dos discos rígidos, o tempo de transferência de setores conse- 
cutivos dentro de uma trilha pode ser muito rápido. Assim, ler mais dados do que o solicitado 
e armazená-los em cache, na memória, pode ser muito eficiente para acelerar o acesso ao 
disco. 


Algoritmos de escalonamento do braço do disco 


Se o driver de disco aceita uma requisição por vez e as executa na ordem que as recebe, isto 
é, a primeira a chegar é a primeira a ser atendida (FCFS — First-Come, First-Served), pouco 
pode ser feito para melhorar o tempo de busca. Entretanto, outra estratégia é possível quando 
o disco está sendo muito acessado. É provável que, enquanto o braço esteja fazendo uma 
busca para atender uma requisição, outras requisições de acesso ao disco estão sendo geradas 
por outros processos. Muitos drivers de disco mantêm uma tabela, indexada pelo número do 
cilindro, com todas as requisições pendentes para cada cilindro, concatenadas em uma lista 
encadeada encabeçada pelas entradas da tabela. 

Dado esse tipo de estrutura de dados, podemos aprimorar o algoritmo de escalonamento 
FCFS. Para entender como, considere um disco com 40 cilindros. Chega uma requisição para 
ler um bloco no cilindro 11. Enquanto a busca do cilindro 11 está em andamento, chegam 
novas requisições para os cilindros 1, 36, 16, 34, 9 e 12, nessa ordem. Eles são inseridos na 
tabela de requisições pendentes, com uma lista encadeada separada para cada cilindro. As 
requisições aparecem na Figura 3-21. 


Posição Requisições 
inicial pendentes 


0 5 10 15 20 25 30 35 Cilindro 


Sequência de buscas 


—— Tempo 


Figura 3-21 Algoritmo de escalonamento de disco da busca mais curta primeiro (SSF — 
Shortest Seek First). 


Quando a requisição corrente (para o cilindro 11) tiver terminado, o driver de disco 
poderá escolher qual requisição vai atender em seguida. Usando FCFS, ele iria em seguida 
para o cilindro 1, depois para o 36 e assim por diante. Esse algoritmo exigiria movimentos do 
braço de 10, 35, 20, 18, 25 e 3, respectivamente, para um total de 111 cilindros. 

Como alternativa, ele poderia sempre tratar da requisição seguinte mais próxima para 
minimizar o tempo de busca. Dados as requisições da Figura 3-21, a sequência é 12,9, 16,1, 
34 e 36, como mostrado pela linha irregular na parte inferior da figura. Com essa seqiiência, 
os movimentos do braço são 1,3, 7, 15, 33 e 2, para um total de 61 cilindros. Esse algoritmo, 
da busca mais curta primeiro (SSF — Shortest Seek First), reduz o movimento total do 
braço quase pela metade, comparado ao algoritmo FCFS. 
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Infelizmente, o algoritmo SSF tem um problema. Suponha que mais requisições conti- 
nuem chegando, enquanto as requisições da Figura 3-2 1 estão sendo atendidas. Por exemplo, se, 
após ir para o cilindro 16, uma nova requisição para o cilindro 8 estiver presente, essa requisição 
terá prioridade sobre o cilindro 1. Se, então, chegar uma requisição para o cilindro 13, o braço 
irá em seguida para 13, em vez de ir para 1. Com um disco sendo muito acessado, o braço tende- 
rá a ficar no meio do disco a maior parte do tempo; portanto, as requisições relativas aos extre- 
mos terão de esperar até que uma flutuação estatística na carga faça com que não haja nenhuma 
requisição próxima do meio. As requisições longe do meio podem obter um serviço deficiente. 
Os objetivos do tempo de resposta mínimo e da imparcialidade estão em conflito aqui. 

Os edifícios altos também precisam lidar com esse compromisso. O problema do fun- 
cionamento de um elevador em um edifício alto é semelhante ao do escalonamento do braço 
de um disco. As requisições chegam continuamente, chamando o elevador para os andares 
(cilindros) aleatoriamente. O microprocessador que controla o elevador poderia facilmente 
monitorar a sequência em que os usuários pressionaram o botão de chamada e atendê-los 
usando um algoritmo FCFS. Ele também poderia usar o algoritmo SSF. 

Entretanto, a maioria dos elevadores utiliza um algoritmo diferente para atender às 
exigências contraditórias da eficiência e da imparcialidade. Eles continuam a se mover na 
mesma direção até que não existam mais chamadas pendentes nessa direção e, então, mudam 
de direção. Esse algoritmo, conhecido tanto no mundo dos discos quanto no mundo dos ele- 
vadores como algoritmo do elevador, exige que o software mantenha 1 bit: o bit de direção 
corrente, UP ou DOWN. Quando uma requisição termina, o driver de disco ou de elevador 
verifica o bit. Se ele for UP, o braço ou a cabine é movido para a próxima requisição pendente 
mais alta. Se não houver nenhuma requisição pendente nas posições mais altas, o bit de dire- 
ção será invertido. Quando o bit é configurado como DOWN, o movimento é para a próxima 
posição mais baixa solicitada, se houver. 

A Figura 3-22 mostra o algoritmo do elevador usando os mesmos sete pedidos da Fi- 
gura 3-21, supondo que o bit de direção era inicialmente UP. A ordem na qual os cilindros 
são atendidos é 12, 16, 34, 36, 9 e 1, o que produz movimentos do braço de 1, 4, 18,2,27 e 
8, para um total de 60 cilindros. Neste caso, o algoritmo do elevador é ligeiramente melhor 
do que o SSF, embora normalmente seja pior. Uma propriedade interessante do algoritmo do 
elevador é que, dado um conjunto de requisições, o limite superior do movimento total é fixo: 
é simplesmente duas vezes o número de cilindros. 


Posição 
inicial 


35 Cilindro 


Sequência de buscas 


—— Tempo 


Figura 3-22 O algoritmo do elevador atender requisições de disco. 


Uma ligeira modificação desse algoritmo, que tem uma disparidade menor nos tempos 
de resposta, é sempre varrer na mesma direção (Teory, 1972). Após o cilindro de numeração 
mais alta, associado a uma requisição pendente, tiver sido acessado, o braço é deslocado para 
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o cilindro de numeração mais baixa com uma requisição pendente. A partir daí, o braço con- 
tinua seu movimento em direção aos cilindros mais altos atendendo as requisições pendentes 
associadas. Na prática, o cilindro de numeração mais baixa é considerado como estando ime- 
diatamente acima do cilindro de numeração mais alta. 

Algumas controladoras de disco oferecem uma maneira para o software inspecionar o 
número do setor que está correntemente sob o cabeçote. Com essa controladora, outra me- 
lhoria é possível. Se duas ou mais requisições para o mesmo cilindro estiverem pendentes, o 
driver pode fazer atender a requisição para o próximo setor que passará sob o cabeçote. Note 
que, quando várias trilhas estão presentes em um cilindro, requisições consecutivas podem 
ser para trilhas diferentes, sem nenhuma penalidade. A controladora pode selecionar qualquer 
um de seus cabeçotes instantaneamente, pois a seleção do cabeçote não envolve nem o movi- 
mento do braço nem um atraso rotacional. 

Em um disco rígido moderno, a taxa de transferência de dados é tão rápida que é ne- 
cessário o uso de algum tipo de cache. Normalmente, dependendo do espaço disponível na 
memória de cache da controladora de disco, toda requisição para ler um setor fará esse setor 
e todo o restante da trilha corrente serem lidos. As caches atuais fregiientemente são de 8 MB 
ou mais. 

Quando estão presentes várias unidades de disco, deve ser mantida uma tabela de re- 
quisições pendentes para cada unidade de disco separadamente. Quando uma unidade de 
disco está ociosa, deve ser feita uma busca para mover seu braço até o cilindro onde ele será 
necessário em seguida (supondo que a controladora permita buscas sobrepostas). Quando a 
transferência corrente termina, pode ser feita uma verificação para ver se unidades de disco 
estão posicionadas no cilindro correto. Se uma ou mais estiverem, a próxima transferência 
poderá ser iniciada em uma unidade de disco que já está no cilindro correto. Se nenhum dos 
braços estiver no lugar certo, o driver deverá fazer uma nova busca na unidade de disco que 
acabou de completar uma transferência e esperar até a próxima interrupção para ver qual 
braço chega ao seu destino primeiro. 


Tratamento de erros 


Os discos de RAM não precisam se preocupar em otimizar o tempo de busca ou de latência 
rotacional: a qualquer momento, todos os blocos podem ser lidos ou escritos, sem nenhum 
movimento físico. Outra área onde os discos de RAM são mais simples do que os discos reais 
é o tratamento de erros. Os discos de RAM sempre funcionam; os reais, nem sempre. Eles 
estão sujeitos a uma grande variedade de erros. Alguns dos mais comuns são: 


1. Erro de programação (por exemplo, requisição para um setor inexistente). 


2. Erro de soma de verificação temporário (causado, por exemplo, por poeira no ca- 
beçote). 

3. Erro de soma de verificação permanente (por exemplo, um bloco de disco fisica- 
mente danificado). 


4. Erro de busca (por exemplo, o braço foi enviado para o cilindro 6, mas foi para o 7). 


5. Erro de controladora (por exemplo, a controladora se recusa a aceitar comandos). 


Cabe ao driver de disco tratar de cada um deles o melhor que puder. 

Os erros de programação ocorrem quando o driver diz à controladora para que bus- 
que um cilindro inexistente, leia um setor inexistente, use um cabeçote inexistente ou faça 
uma transferência para (ou de) memória inexistente. A maioria das controladoras verifica 
os parâmetros recebidos e reclama se eles forem inválidos. Teoricamente, esses erros nunca 
devem ocorrer, mas o que o driver deve fazer se a controladora indicar que um deles ocorreu? 
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Para um sistema feito em casa, o melhor a fazer é parar e imprimir uma mensagem como 
“Chame o programador”, para que o erro possa ser encontrado e corrigido. Para um produto 
de software comercial, em uso em milhares de lugares ao redor do mundo, essa estratégia é 
menos atraente. Provavelmente, a única coisa a fazer é terminar a requisição de disco corrente 
com um erro e esperar que ele não se repita com muita frequência. 

Os erros de soma de verificação temporários são causados por partículas de poeira no 
ar que acabam ficando entre o cabeçote e a superfície do disco. Na maioria das vezes, eles 
podem ser eliminados apenas repetindo-se a operação algumas vezes. Se o erro persistir, o 
bloco terá de ser marcado como um bloco defeituoso (bad block) e evitado. 

Uma maneira de evitar blocos defeituosos é escrever um programa especial que receba 
a lista de blocos defeituosos e crie um arquivo que finja utilizá-los. Uma vez feito esse arqui- 
vo, o alocador de disco pensará que esses blocos estão ocupados e nunca os alocará. Contanto 
que ninguém jamais tente ler o arquivo de blocos defeituosos, não haverá nenhum problema. 

Não ler o arquivo de blocos defeituosos é mais fácil de dizer do que fazer. O backup de 
muitos discos é feito copiando-se seu conteúdo uma trilha por vez em uma fita de backup ou 
em uma unidade de disco. Se esse procedimento for seguido, os blocos defeituosos causarão 
problemas. Fazer o backup do disco um arquivo por vez é mais lento, mas resolverá o pro- 
blema, desde que o programa de backup saiba o nome do arquivo de blocos defeituosos e se 
abstenha de copiá-lo. 

Outro problema que não pode ser resolvido com um arquivo de blocos defeituosos é 
o de um bloco defeituoso em uma estrutura de dados do sistema de arquivos que deve estar 
em uma posição fixa. Quase todos os sistemas de arquivos têm pelo menos uma estrutura de 
dados cuja posição é fixa; portanto, ela pode ser encontrada facilmente. Em um sistema de 
arquivos particionado, é possível fazer novamente a partição e contornar uma trilha defei- 
tuosa, mas um erro permanente nos primeiros setores de um disquete ou de um disco rígido 
geralmente significa que o disco é inutilizável. 

As controladoras “inteligentes” reservam algumas trilhas normalmente não disponíveis 
para programas de usuário. Quando uma unidade de disco é formatada, a controladora de- 
termina quais blocos são defeituosos e substitui automaticamente a trilha defeituosa por uma 
das trilhas sobressalentes. A tabela que faz o mapeamento de trilhas defeituosas para trilhas 
sobressalentes é mantida na memória interna da controladora e no disco. Essa substituição é 
transparente (invisível) para o driver, exceto que seu algoritmo do elevador cuidadosamente 
elaborado pode ter baixo desempenho, caso a controladora esteja usando secretamente o ci- 
lindro 800, quando o cilindro 3 for solicitado. A tecnologia atual de fabricação de superfícies 
de gravação de disco é melhor do que era antigamente, mas ainda não é perfeita. Entretanto, 
a tecnologia de esconder do usuário as imperfeições também melhorou. Muitas controladoras 
também gerenciam novos erros que podem se manifestar com o uso, atribuindo blocos subs- 
titutos permanentemente, quando determinam que um erro é irrecuperável. Com esses discos, 
o software do driver raramente vê qualquer indicação de que existem blocos defeituosos. 

Os erros de busca são causados por problemas mecânicos no braço. A controladora 
monitora a posição do braço internamente. Para realizar uma busca, ela emite uma série de 
pulsos para o motor do braço, um pulso por cilindro, para mover o braço para o novo cilindro. 
Quando o braço chega ao seu destino, a controladora lê o número real do cilindro (gravado 
quando a unidade de disco foi formatada). Se o braço estiver no lugar errado, ocorreu um erro 
de busca e é necessária alguma ação corretiva. 

A maioria das controladoras de disco rígido corrige erros de busca automaticamente, 
mas muitas controladoras de disquete (incluindo os computadores IBM PC) apenas ativam 
um bit de erro e deixam o resto para o driver. O driver trata desse erro executando um coman- 
do recalibrate para mover o braço o mais longe que puder ir e considerar essa posição como o 
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cilindro zero (inicial). Normalmente, isso resolve o problema. Se não resolver, a unidade de 
disco deverá ser reparada. 

Como vimos, a controladora é na realidade um pequeno computador especializado 
completo, com software, variáveis, buffers e, ocasionalmente, erros. Às vezes, uma segiiência 
de eventos incomum, como uma interrupção em uma unidade de disco ocorrendo simulta- 
neamente com um comando recalibrate para outra unidade de disco, desencadeará um erro 
e fará a controladora entrar em um laço ou esquecer o que estava fazendo. Normalmente, os 
projetistas de controladoras se preparam para o pior e fornecem um pino de reset no chip que, 
quando ativado, obriga a controladora a esquecer o que estava fazendo e a se reconfigurar. Se 
tudo mais falhar, o driver de disco poderá acionar esse pino. Se isso não ajudar, tudo que o 
driver poderá fazer será imprimir uma mensagem e desistir. 


Fazendo cache de uma trilha por vez 


O tempo exigido para buscar um novo cilindro normalmente é muito maior do que o atraso 
rotacional e é sempre significativamente maior do que o tempo de transferência para ler ou 
escrever um setor. Em outras palavras, uma vez que o driver tenha resolvido o problema de 
mover o braço para algum lugar, dificilmente importa se ele lê um único setor ou uma trilha 
inteira. Esse efeito é particularmente verdadeiro se a controladora fornecer percepção rota- 
cional, de modo que o driver possa ver qual setor está correntemente sob o cabeçote e execute 
uma requisição para o próximo setor, tornando com isso possível ler uma trilha inteira do 
disco no tempo de uma única rotação. (Normalmente, em média, para ler um único setor se 
demora meia rotação, mais o tempo de transferência de dados de um setor) 

Alguns drivers de disco tiram proveito dessas propriedades de temporização, mantendo 
uma cache secreta de uma trilha por vez, desconhecida do software independente de dispo- 
sitivo. Se um setor que está na cache é necessário, nenhuma transferência de disco é exigida. 
Uma desvantagem da cache de uma trilha por vez (além da complexidade do software e do 
espaço em buffer necessário) é que as transferências da cache para o programa que fez a cha- 
mada terão de ser feitas pela CPU executando um laço de programa, em vez de permitir que 
o hardware de DMA realize o trabalho. 

Algumas controladoras levam esse processo um passo adiante e fazem uso da cache 
de uma trilha por vez em sua própria memória interna, de forma transparente para o driver, 
para que a transferência entre a controladora e a memória possa usar DMA. Se a controladora 
funciona desse jeito, há pouco sentido em ter o driver de disco fazendo isso também. Note 
que a controladora e o driver estão em boa posição para ler e escrever trilhas inteiras com um 
único comando, mas note que o software independente de dispositivo não pode fazer isso, 
pois enxerga um disco como uma sequência linear de blocos, sem considerar como eles estão 
divididos em trilhas e cilindros. Apenas a controladora conhece a geometria real com toda 
certeza. 


Visão geral do driver de disco rígido no MINIX 3 


O driver de disco rígido é a primeira parte que vimos do MINIX 3 que precisa tratar com uma 
variedade de tipos diferentes de hardware. Antes de discutirmos o driver, consideraremos 
brevemente alguns dos problemas que as diferenças de hardware podem causar. 

O “PC” é, na realidade, uma família de computadores diferentes. Não apenas são usa- 
dos processadores diferentes nos diversos membros da família, mas também existem algumas 
diferenças importantes no hardware básico. O MINIX 3 foi desenvolvido em sistemas mais 
recentes (e para eles), com CPUs da classe Pentium, mas mesmo entre eles, existem diferen- 
ças. Por exemplo, os sistemas Pentium mais antigos utilizam o barramento AT de 16 bits, ori- 
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ginalmente projetado para o processador 80286. Uma característica do barramento AT é que 
ele foi inteligentemente projetado para que os periféricos de 8 bits mais antigos ainda pudes- 
sem ser usados. Posteriormente, os sistemas adicionaram um barramento PCI de 32 bits para 
periféricos, enquanto ainda forneciam entradas de barramento AT. Os projetos mais recentes 
têm eliminado o suporte para o barramento AT, fornecendo apenas um barramento PCI. Mas é 
razoável esperar que os usuários com computadores de certa idade queiram utilizar o MINIX 
3 com uma mistura de periféricos de 8, 16 e 32 bits. 

Para cada barramento existe uma família diferente de adaptadores de E/S. Nos sis- 
temas mais antigos, eles são placas de circuito separadas que se conectam na placa-mãe do 
sistema. Nos sistemas mais recentes, vários adaptadores padrão, especialmente controladoras 
de disco, são partes integrantes do conjunto de chips da placa-mãe. Em si, isso não é pro- 
blema para o programador, pois os adaptadores integrados normalmente têm uma interface 
de software idêntica à dos dispositivos removíveis. Além disso, as controladoras integradas 
normalmente podem ser desativadas. Isso possibilita o uso de um dispositivo complementar 
mais avançado, como uma controladora SCSI, no lugar de um dispositivo incorporado. Para 
tirar proveito dessa flexibilidade, o sistema operacional não deve ficar restrito a usar apenas 
um tipo de adaptador. 

Na família IBM PC, assim como na maioria dos outros sistemas de computador, cada 
projeto de barramento também vem com firmware na ROM BIOS (Basic E/S System Read- 
Only Memory), que é feita para preencher a lacuna entre o sistema operacional e as peculia- 
ridades do hardware. Alguns dispositivos periféricos podem até fornecer extensões para a 
BIOS em chips de memória ROM nas próprias placas do periférico. A dificuldade enfrentada 
por um projetista de sistema operacional é que a BIOS dos computadores do tipo IBM (certa- 
mente os primeiros) foi projetada para um sistema operacional, o MS-DOS, que não suporta 
multiprogramação e que é executado no modo real de 16 bits, o mínimo denominador comum 
dos vários modos de operação disponíveis na família de processadores 80x86. 

O projetista de um novo sistema operacional para o IBM PC defronta-se, assim, com vá- 
rias opções. Uma delas é se vai utilizar o suporte do driver para periféricos na BIOS ou se vai 
escrever novos drivers desde o início. Essa não foi uma escolha difícil no projeto das primeiras 
versões do MINIX, pois, sob vários aspectos, a BIOS não era conveniente para suas necessi- 
dades. É claro que, para executar o MINIX 3, o monitor de inicialização utiliza a BIOS para 
fazer a carga inicial do sistema, seja a partir de disco rígido, CD-ROM ou disquete — não há 
nenhuma alternativa prática para fazer isso dessa maneira. Uma vez que tenhamos carregado o 
sistema, incluindo nossos próprios drivers de E/S, podemos fazer melhor do que a BIOS. 

A segunda escolha, então, deve ser encarada: sem o suporte da BIOS, como faremos 
nossos drivers se adaptarem aos tipos variados de hardware nos diferentes sistemas? Para 
tornar a discussão concreta, considere que existem dois tipos fundamentalmente diferentes de 
controladora de disco rígido que podem ser utilizados nos sistemas Pentium de 32 bits moder- 
nos, para os quais o MINIX 3 foi projetado: a controladora IDE integrada e as controladoras 
SCSI para o barramento PCI. Se você quiser tirar proveito de hardware mais antigo e adaptar 
o MINIX 3 para funcionar no hardware destinado às versões anteriores do MINIX, existem 
quatro tipos de controladora de disco rígido a considerar: a controladora tipo XT de 8 bits 
original, a controladora tipo AT de 16 bits e duas controladoras diferentes para computadores 
da série IBM PS/2. Existem várias maneiras possíveis de lidar com todas essas alternativas: 


1. Recompilar uma versão exclusiva do sistema operacional para cada tipo de contro- 
ladora de disco rígido que precisamos acomodar. 


2. Incluir vários drivers de disco rígido diferentes na imagem de inicialização e fa- 
zer o sistema determinar automaticamente, no momento da inicialização, qual vai 
usar. 
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3. Incluir vários drivers de disco rígido diferentes na imagem de inicialização e for- 
necer uma maneira para o usuário determinar qual vai usar. 


Conforme veremos, essas alternativas não são mutuamente exclusivas. 

A primeira é a melhor opção a longo prazo. Para uso em uma instalação em particular, 
não há necessidade de utilizar espaço em disco e de memória com código de drivers alterna- 
tivos que nunca serão usados. Entretanto, isso é um pesadelo para o distribuidor do software. 
Fornecer quatro discos de inicialização diferentes e informar aos usuários sobre como uti- 
lizá-los é caro e difícil. Assim, é aconselhável outro método, pelo menos para a instalação 
inicial. 

O segundo método é fazer com que o sistema operacional investigue os periféricos, len- 
do a memória ROM de cada placa ou escrevendo e lendo portas de E/S para identificar cada 
uma. Isso é possível (e funciona melhor nos sistemas tipo IBM mais recentes do que nos mais 
antigos), mas não atende os dispositivos de E/S não padronizados. Além disso, investigar 
portas de E/S para identificar um único dispositivo às vezes pode ativar outro dispositivo que 
se apodera do código e desativa o sistema. Esse método complica o código de inicialização 
de cada dispositivo e ainda não funciona muito bem. Os sistemas operacionais que utilizam 
esse método geralmente precisam fornecer algum tipo de saída, normalmente um mecanismo 
como o que usamos no MINIX 3. 

O terceiro método, usado no MINIX 3, é permitir a inclusão de vários drivers na ima- 
gem de inicialização. O monitor de inicialização do MINIX 3 permite que vários parâmetros 
de inicialização (boot parameters) sejam lidos no momento da partida do sistema. Eles po- 
dem ser inseridos manualmente ou armazenados permanentemente no disco. No momento da 
partida do sistema, se for encontrado um parâmetro de inicialização da forma 


label = AT 


isso obrigará a controladora de disco IDE (at wini) a ser usada quando o MINIX 3 for inicia- 
do. Isso depende do driver at wini que estiver sendo atribuído a esse rótulo. Os rótulos são 
atribuídos quando a imagem de inicialização é compilada. 

O MINIX 3 faz duas outras coisas para tentar minimizar os problemas dos múltiplos 
drivers de disco rígido. Uma delas é que, afinal, existe um driver que faz a interface entre o 
MINIX 3 e o suporte de disco rígido da ROM BIOS. É quase certo que esse driver funciona 
em qualquer sistema e pode ser selecionado pelo uso de um parâmetro de inicialização 


label=BIOS 


Geralmente, contudo, esse deve ser um último recurso. O MINIX 3, conforme descrito 
aqui, só é executado no modo protegido em sistemas com um processador 80386 ou mais re- 
cente, mas o código da BIOS sempre é executado no modo real (8086). É muito lento chavear 
para o modo protegido e voltar novamente, quando for chamada uma rotina na BIOS. 

A outra estratégia utilizada pelo MINIX 3 no tratamento com drivers é adiar a ini- 
cialização até o último momento possível. Assim, se em alguma configuração de hardware, 
nenhum dos drivers de disco rígido funcionar, ainda poderemos iniciar o MINIX 3 a partir 
de um disquete e realizar algum trabalho útil. O MINIX 3 não terá problema algum, desde 
que não sejam feitas tentativas de acessar o disco rígido. Isso pode não parecer um grande 
avanço na interface com o usuário, mas considere isto: se todos os drivers tentarem inicializar 
imediatamente na partida do sistema, este poderá ficar totalmente paralisado por causa da 
configuração incorreta de algum dispositivo que, de qualquer forma, não precisamos. Mas, 
adiando-se a inicialização de cada driver até que ele seja necessário, o sistema pode continuar 
com o que funciona, enquanto o usuário tenta resolver os problemas. 
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Aprendemos essa lição do jeito mais difícil: as versões anteriores do MINIX tentavam 
inicializar o disco rígido assim que o sistema era inicializado. Se nenhum disco rígido es- 
tivesse presente, o sistema travava. Esse comportamento era especialmente infeliz, pois o 
MINIX funciona muito bem em um sistema sem disco rígido, se bem que com capacidade de 
armazenamento restrita e desempenho reduzido. 

Na discussão desta seção e da próxima, tomaremos como modelo o driver de disco rígi- 
do estilo AT, que é o driver padrão na distribuição padrão do MINIX 3. Trata-se de um driver 
versátil, que manipula desde as controladoras de disco rígido usadas nos primeiros sistemas 
80286 até as modernas controladoras EIDE (Extended Integrated Drive Electronics), que 
manipulam discos rígidos com capacidade na casa dos gigabytes. As controladoras EIDE 
modernas também suportam unidades de CD-ROM padrão. Entretanto, para simplificar nossa 
discussão, as extensões que suportam CD-ROMs foram retiradas do código listado no Apên- 
dice B. Os aspectos gerais da operação do disco rígido que discutimos nesta seção também se 
aplicam aos outros drivers suportados. 

O laço principal do driver de disco rígido é o mesmo código comum que já discutimos e 
suporta os nove tipos de requisição padrão que podem ser feitas. Uma requisição DEV OPEN 
pode acarretar um volume de trabalho substancial, pois em um disco rígido sempre existem 
partições e pode haver subpartições. Elas devem ser lidas quando um dispositivo é aberto 
(isto é, quando ele é acessado pela primeira vez). Quando são suportados CD-ROMs, em uma 
requisição DEV OPEN, a presença da mídia deve ser verificada, pois ela é removível. Em um 
CD-ROM, uma operação DEV CLOSE também tem significado: ela exige que a porta seja 
aberta e o CD-ROM ejetado. Existem outras complicações da mídia removível que são mais 
aplicáveis às unidades de disquete; portanto, as discutiremos em uma seção posterior. Para 
CD-ROMs, uma operação DEV JOCTL é usada para ativar um flag indicando que a mídia 
deve ser ejetada da unidade de disco depois de uma operação DEV CLOSE. A operação 
DEV IOCTL também é usada para ler e escrever tabelas de partição. 

As requisições DEV READ, DEV WRITE, DEV. GATHER e DEV SCATTER são ma- 
nipulados em duas fases, preparar e transferir, como vimos anteriormente. Para o disco rígi- 
do, as chamadas de DEV. CANCEL e DEV SELECT são ignoradas. 

Nenhum escalonamento é realizado pelo driver de dispositivo de disco rígido; isso é 
feito pelo sistema de arquivos, que monta o vetor de requisições para reunir/dispersar E/S. 
As requisições vêm da cache do sistema de arquivos como pedidos DEV GATHER ou 
DEV SCATTER para múltiplos de blocos (4 KB na configuração padrão do MINIX 3), mas o 
driver de disco rígido é capaz de tratar de requisições de qualquer múltiplo de um setor (512 
bytes). Em qualquer caso, como vimos, o laço principal de todos os drivers de disco transfor- 
ma as requisições de blocos de dados simples em um vetor de requisições de um só elemento. 

As requisições de leitura e de escrita não são misturadas no vetor de requisições nem 
são marcadas como opcionais. Os elementos de um vetor de requisições são para setores ad- 
jacentes do disco e o vetor é classificado pelo sistema de arquivos, antes de ser passado para 
o driver de dispositivo; portanto, basta especificar a posição inicial no disco para um array 
inteiro de requisições. 

Espera-se que o driver tenha sucesso na leitura ou na escrita pelo menos da primeira 
requisição de um vetor de requisições e que retorne quando uma requisição falhar. Cabe ao 
sistema de arquivos decidir o que fazer; o sistema de arquivos tentará concluir uma operação 
de escrita, mas retornará para o processo que fez a chamada apenas os dados que puder obter 
em uma leitura. 

O próprio sistema de arquivos, usando E/S dispersa, pode implementar algo semelhan- 
te à versão de Teory do algoritmo do elevador — lembre-se de que, em uma requisição de 
E/S dispersa, a lista de requisições é classificada pelo número do bloco. A segunda etapa do 
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escalonamento ocorre na controladora de um disco rígido. As controladoras modernas são 
“inteligentes” e podem colocar grandes volumes de dados no buffer, usando internamente 
algoritmos para recuperar dados na ordem mais eficiente, sem levar em consideração a ordem 
de recebimento das requisições. 


Implementação do driver de disco rígido no MINIX 3 


Os discos rígidos usados em microcomputadores às vezes são chamados de discos winchester. 
O termo era o nome de código da IBM para o projeto que desenvolveu a tecnologia de disco 
onde os cabeçotes de leitura/gravação flutuam sobre uma fina almofada de ar e pousam na 
mídia de gravação quando o disco pára de girar. A explicação do nome é que um modelo 
anterior tinha dois módulos para armazenamento de dados, um fixo, de 30 Mbytes, e um 
removível, de 30 Mbytes. Supostamente, isso lembrava aos desenvolvedores a arma de fogo 
Winchester 30-30 que aparecem em muitas histórias de faroeste dos Estados Unidos. Qual- 
quer que seja a origem do nome, a tecnologia básica permanece a mesma, embora o disco de 
PC típico de hoje seja fisicamente muito menor e a capacidade muito maior do que os discos 
de 14 polegadas do início dos anos 70, quando a tecnologia do winchester foi desenvolvida. 

O driver de disco rígido estilo AT do MINIX 3 é dado em at wini.c (linha 12100). Esse 
é um driver complicado para um dispositivo sofisticado e há várias páginas de definições de 
macro especificando registradores de controladora, bits de status e comandos, estruturas de 
dados e prototypes. Assim como nos outros drivers de dispositivo de bloco, uma estrutura 
driver, w dtab (linhas 12316 a 12331), é inicializada com ponteiros para as funções que real- 
mente fazem o trabalho. A maior parte delas está definida em at wini.c, mas como o disco 
rígido não exige nenhuma operação de limpeza especial, sua entrada dr cleanup aponta para 
a função comum nop cleanup em driver.c, compartilhada com outros drivers que não têm ne- 
nhum requisito de limpeza especial. Várias outras funções possíveis também são irrelevantes 
para esse driver e também são inicializadas de modo a apontar para funções nop . A função 
de entrada, at winchester task (linha 12336), chama uma função que faz a inicialização 
específica do hardware e o laço principal em driver.c, passando o endereço de w dtab. O laço 
principal, driver task, em libdriver/driver.c, é eternamente executado despachando chamadas 
para as diversas funções apontadas pela tabela driver. 

Como estamos tratando agora com dispositivos de armazenamento eletromecânicos 
reais, há um volume de trabalho substancial a ser feito por init params (linha 12347) para 
inicializar o driver de disco rígido. Vários parâmetros sobre os discos rígidos são mantidos 
na tabela wini, definida nas linhas 12254 a 12276, que tem um elemento para cada uma das 
unidades de disco MAX DRIVES (8) suportadas, até quatro unidades de disco IDE conven- 
cionais e até quatro unidades de disco no barramento PCI, com controladoras plug-in IDE ou 
SATA (Serial AT Attachment). 

Seguindo a política de adiar as etapas de inicialização que poderiam falhar até a primei- 
ra vez que elas sejam realmente necessárias, init params não faz nada que exija acesso aos 
dispositivos de disco em si. Sua principal atividade é copiar informações sobre a configuração 
do disco rígido lógico no array wini. A ROM BIOS de um computador da classe Pentium re- 
cupera as informações de configuração básica da memória CMOS usada para preservar esses 
dados. A BIOS faz isso quando o computador é ligado pela primeira vez, antes do início da 
primeira parte do processo de carga do MINIX 3. Nas linhas 12366 a 12392, as informações 
são copiadas da BIOS. Muitas das constantes usadas aqui, como NR HD DRIVES ADDR, 
são definidas em include/ibm/bios.h, um arquivo que não está listado no Apêndice B, mas que 
pode ser encontrado no CD-ROM do MINIX 3. Não é necessariamente importante se essas 
informações não puderem ser recuperadas. Se o disco for moderno, as informações podem 
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ser recuperadas diretamente dele, quando for acessado pela primeira vez. Após a entrada dos 
dados obtidos da BIOS, são preenchidas informações de disco adicionais para cada unidade 
de disco, usando uma chamada para a função seguinte, init drive. 

Nos sistemas mais antigos, com controladoras IDE, o disco funciona como se fosse uma 
placa de periférico estilo AT, mesmo que possa estar integrado na placa-mãe. Normalmente, 
as controladoras de unidade de disco modernas funcionam como dispositivos PCI, com um 
caminho de dados de 32 bits para a CPU, em vez do barramento AT de 16 bits. Felizmente 
para nós, uma vez terminada a inicialização, as interfaces para as duas gerações de controla- 
dora de disco parecem iguais para o programador. Para fazer isso funcionar, init params pci 
(linha 12437) é chamada, se necessário, para obter os parâmetros dos dispositivos PCI. Não 
vamos descrever os detalhes dessa rotina, mas alguns pontos devem ser mencionados. Primei- 
ramente, o parâmetro de inicialização ata instance é usado na linha 12361 para configurar o 
valor da variável w instance. Se o parâmetro de inicialização não for configurado explicita- 
mente, o valor será zero. Se ele for configurado e for maior do que zero, o teste na linha 12365 
causa uma consulta à BIOS e a inicialização de unidades de disco IDE padrão não é feita. 
Neste caso, apenas as unidades de disco encontradas no barramento PCI serão registradas. 

O segundo ponto é que uma controladora encontrada no barramento PCI será identifi- 
cada como os dispositivos de controle c0d4 a cOd7. Se w instance for diferente de zero, os 
identificadores de unidade de disco cÓdO a cOd3 não serão usados, a não ser que uma contro- 
ladora de barramento PCI identifique a si mesma como “compatível”. As unidades de disco 
manipuladas por uma controladora de barramento PCI compatível serão designadas de cOdO 
a c0d3. Para a maioria dos usuários do MINIX 3, todas essas complicações provavelmente 
podem ser ignoradas. Um computador com menos de quatro unidades de disco (incluindo a 
unidade de CD-ROM), provavelmente aparecerá para o usuário como tendo a configuração 
clássica, com as unidades de disco designadas de c0d0 a c0d3, estejam elas conectadas em 
controladoras IDE ou PCI e estejam utilizando ou não os conectores paralelos de 40 pinos 
clássicos ou conectores seriais mais recentes. Mas a programação exigida para dar essa ilusão 
é complicada. 

Após a chamada para o laço principal comum nada mais é feito até que ocorra a pri- 
meira tentativa de acessar o disco rígido. Quando for feita a primeira tentativa de acesso a 
um disco, uma mensagem solicitando uma operação DEV OPEN será recebida pelo laço 
principal e w do open (linha 12521) será chamada indiretamente. Por sua vez, w do open 
chamará w prepare para determinar se o dispositivo solicitado é válido e, então, chamará 
w identify para identificar o tipo de dispositivo e inicializar mais alguns parâmetros no array 
wini. Finalmente, um contador é usado no array wini para testar se essa é a primeira vez que 
o dispositivo foi aberto desde que o MINIX 3 foi iniciado. Após ser examinado, o contador é 
incrementado. Se essa for a primeira operação DEV OPEN, a função partition (em drvlib.c) 
será chamada. 

A próxima função, w prepare (linha 12577), aceita um argumento inteiro, device, que 
é o número secundário de dispositivo da unidade de disco ou partição a ser usada, e retorna 
um ponteiro para a estrutura device indicando o endereço de base e o tamanho do dispositivo. 
Na linguagem C, o uso de um identificador para nomear uma estrutura não impede o uso do 
mesmo identificador para nomear uma variável. Se um dispositivo é uma unidade de disco, 
uma partição ou uma subpartição, isso pode ser determinado a partir do número secundário 
do dispositivo. Quando w prepare tiver terminado seu trabalho, nenhuma das outras funções 
usadas para leitura ou escrita no disco precisará se preocupar com o particionamento. Como 
vimos, w. prepare é chamada quando é feito uma requisição DEV OPEN, isso também é 
uma fase do ciclo preparação/transferência usado por todos as requisições de transferência 
de dados. 
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Discos com software compatível ao estilo AT estiveram em uso por um bom tempo 
e w identify (linha 12603) precisa distinguir entre os vários projetos diferentes que foram 
introduzidos com o passar dos anos. O primeiro passo é ver se existe uma porta de E/S que 
possa ser lida e escrita, onde deveria existir uma em todas as controladoras de disco dessa 
família. Esse é o primeiro exemplo que vemos de acesso à porta de E/S feito por um driver 
em espaço de usuário e a operação merece uma descrição. Para um dispositivo de disco, a E/S 
é feita usando uma estrutura command, definida nas linhas 12201 a 12208, que é preenchida 
com uma série de valores de byte. Vamos descrever isso com um pouco mais de detalhes 
posteriormente; por enquanto, note que dois bytes dessa estrutura são preenchidos, um com 
o valor ATA IDENTIFY, interpretado como um comando que pede a uma unidade de disco 
ATA (AT Attached) que se identifique, e outro com um padrão de bits que seleciona a unidade 
de disco. Então, com simple é chamada. 

Essa função oculta todo o trabalho de construção de um vetor de sete endereços de porta 
de E/S e os bytes a serem escritos neles, enviando essa informação para a tarefa de sistema, 
esperando por uma interrupção e verificando o status retornado. Isso testa se a unidade de 
disco está ativa e permite que uma string de valores de 16 bits seja lida pela chamada de 
núcleo sys insw, na linha 12629. Decodificar essa informação é um processo confuso e não 
o descreveremos em detalhes. Basta dizer que é recuperado um volume de informação consi- 
derável, incluindo uma string identificando o modelo do disco e os parâmetros preferidos de 
cilindro físico, cabeçote e setor para o dispositivo. (Note que a configuração física relatada 
não precisa ser a configuração física real, mas não temos alternativa a não ser aceitar o que 
a unidade de disco reivindica.) A informação do disco também indica se ele é capaz de fa- 
zer Endereçamento de Bloco Lógico (Logical Block Addressing — LBA) ou não. Se for, o 
driver poderá ignorar os parâmetros de cilindro, cabeçote e setor, e poderá endereçar o disco 
usando números de setor absolutos, o que é muito mais simples. 

Conforme mencionamos anteriormente, é possível que init params não consiga recu- 
perar as informações de configuração do disco lógico das tabelas da BIOS. Se isso acontecer, 
o código nas linhas 12666 a 12674 tentará criar um conjunto de parâmetros apropriados, com 
base no que lê da própria unidade de disco. A idéia é que os números máximos de cilindro, 
cabeçote e setor possam ser 1023, 255 e 63 respectivamente, devido ao número de bits permi- 
tidos para esses campos nas estruturas de dados originais da BIOS. 

Se o comando ATA IDENTIFY falhar, isso pode significar simplesmente que o disco é 
de um modelo mais antigo, que não suporta o comando. Nesse caso, tudo que teremos serão 
os valores de configuração lógicos lidos anteriormente por init params. Se forem válidos, 
eles serão copiados nos campos de parâmetro físico de wini; caso contrário, um erro é retor- 
nado e o disco não poderá ser usado. 

Finalmente, o MINIX 3 usa uma variável u32 t para contar os endereços, em bytes. Isso 
limita o tamanho de uma partição a 4 GB. Entretanto, a estrutura device usada para armazenar 
a base e o tamanho de uma partição (definida em drivers/libdriver/driver.h, nas linhas 10856 
a 10858) utiliza números u64 t e é usada uma operação de multiplicação de 64 bits para cal- 
cular o tamanho da unidade de disco (linha 12688); então, a base e o tamanho da unidade de 
disco inteira são inseridos no array wini e w specify é chamada (duas vezes, se necessário) 
para passar os parâmetros a serem usados de volta para a controladora de disco (linha 12691). 
Finalmente, são feitas mais chamadas de núcleo: uma chamada sys irqsetpolicy (linha 12699) 
garante que, quando ocorrer uma interrupção da controladora de disco e ela for atendida, a 
interrupção será reativada automaticamente, em preparação para a próxima. Depois disso, uma 
chamada de sys irgenable ativa realmente a interrupção. 

W name (linha 12711) retorna um ponteiro para uma string contendo o nome de dis- 
positivo, que será “AT-DO”, “AT-D1”, “AT-D2” ou “AT-D3”. Quando uma mensagem de erro 
precisa ser gerada, essa função informa qual unidade de disco a produziu. 
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É possível que uma unidade de disco se mostre incompatível com o MINIX 3 por algum 
motivo. A função w io test (linha 12723) é fornecida para testar cada unidade de disco na 
primeira vez que é feita uma tentativa de abri-la. Essa rotina tenta ler o primeiro bloco na 
unidade de disco, com valores de tempos limites (timeouts) mais curtos do que os utilizados 
na operação normal. Se o teste falha, a unidade de disco é marcada permanentemente como 
indisponível. 

W specify (linha 12775), além de passar os parâmetros para a controladora, também 
calibra a unidade de disco (se for um modelo mais antigo), fazendo uma busca para o cilin- 
dro zero. 

Do transfer (linha 12814) faz o que seu nome sugere — realiza a transferência. Ela 
monta uma estrutura command com todos os valores de byte necessários para solicitar a 
transferência de um trecho de dados (possivelmente até 255 setores de disco) e, então, chama 
com out, que envia o comando para a controladora de disco. Os dados devem ser formatados 
de formas diferentes, dependendo de como o disco vai ser endereçado; isto é, se vai ser por 
cilindro, cabeçote e setor ou por LBA. Internamente, o MINIX 3 endereça blocos de disco de 
forma linear; portanto, se for suportado LBA, os três primeiros campos do tamanho de um 
byte são preenchidos com os valores resultantes do deslocamento para a direita da contagem 
de setores por um número apropriado de bits e, na sequência, mascarados para se obter valo- 
res de 8 bits. A contagem de setores é um número de 28 bits; portanto, a última operação de 
mascaramento usa uma máscara de 4 bits (linha 12830). Se o disco não suporta LBA, então 
os valores de cilindro, cabeçote e setor são calculados com base nos parâmetros do disco em 
uso (linhas 12833 a 12835). 

O código contém uma previsão de aprimoramento futuro. O endereçamento LBA com 
uma contagem de setores de 28 bits limita o MINIX 3 a utilizar discos de 128 GB ou de tama- 
nho menor. (Você pode usar um disco maior, mas o MINIX 3 só consegue acessar os primei- 
ros 128 GB). Os programadores andam pensando (mas ainda não implementaram) sobre usar 
do método LBA48, que utiliza 48 bits para endereçar blocos de disco. Na linha 12824, é feito 
um teste para saber se isso está habilitado. O teste sempre falhará com a versão do MINIX 3 
descrita aqui. Isso é bom, pois não existe código a ser executado se o teste for bem-sucedido. 
Lembre-se de que, se você decidir modificar o MINIX 3 sozinho para usar LBA48, precisará 
fazer mais do que apenas acrescentar algum código aqui. Será necessário fazer alterações em 
muitos lugares para manipular endereços de 48 bits. Talvez você ache mais fácil esperar até 
que o MINIX 3 também tenha sido portado para um processador de 64 bits. Mas se um disco 
de 128 GB não for grande o bastante para você, o LBA48 proporcionará acesso para 128 PB 
(Petabytes). 

Agora, veremos brevemente como ocorre uma transferência de dados em um nível 
mais alto. A função W prepare, que já discutimos, é chamada primeiro. Se a operação de 
transferência solicitada foi para múltiplos blocos (isto é, uma requisição DEV GATHER ou 
DEV SCATTER), w transfer, linha 12848, será chamada imediatamente a seguir. Se a trans- 
ferência é para um único bloco (uma requisição DEV READ ou DEV WRITE), um vetor de 
dispersão/reunião de um só elemento é criado e, então, w transfer é chamada. De acordo 
com isso, w transfer foi escrita de forma a esperar um vetor de requisições iovec t. Cada ele- 
mento desse vetor consiste no endereço e no tamanho de um buffer, com a restrição de que o 
tamanho deve ser um múltiplo de um setor de disco. Todas as outras informações necessárias 
são passadas como argumento para a chamada e se aplicam ao vetor de requisições inteiro. 

Primeiramente, é feito um teste simples para ver se o endereço de disco solicitado para 
o início da transferência está alinhado em um limite de setor (linha 12863). Então, entra-se 
no laço externo da função. Esse laço se repete para cada elemento do vetor de requisições. 
Dentro do laço, como já vimos muitas vezes, vários testes são feitos antes que o trabalho 
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real da função seja realizado. Primeiro é calculado o número total de bytes que ainda estão 
na requisição, somando-se os campos iov size de cada elemento do vetor de requisições. 
Esse resultado é verificado para garantir que seja um múltiplo exato do tamanho de um setor. 
Outros testes verificam se a posição inicial não está no final ou além do final do dispositivo 
e, se a requisição ultrapassar o final do dispositivo o valor do tamanho será truncado. Todos 
os cálculos até aqui foram feitos em bytes, mas na linha 12876 é feito um cálculo da posição 
do bloco no disco usando aritmética de 64 bits. Note que, embora a variável usada se chame 
block, esse é o número de setores do disco, e não o “bloco” usado internamente pelo MINIX 
3, normalmente de 4096 bytes. Depois disso, é feito mais um ajuste. Toda unidade de disco 
tem um número máximo de bytes que podem ser solicitados por vez e a requisição é ajustada 
de acordo com essa quantidade, se necessário. Após verificar se o disco foi inicializado e 
repetir isso novamente, se necessário, é feita a requisição de um conjunto de dados através da 
chamada a do transfer (linha 12887). 

Após a requisição de transferência, entra-se no laço interno, que se repete para cada 
setor. Para uma operação de leitura escrita, será gerada uma interrupção para cada setor. Em 
uma leitura, a interrupção significa que os dados estão prontos e podem ser transferidos. A 
chamada de núcleo sys insw, na linha 12913, pede à tarefa de sistema para que leia repetida- 
mente a porta de E/S especificada, transferindo os dados para um endereço virtual na área de 
dados do processo especificado. Para uma operação de escrita, a ordem é inversa. A chamada 
de sys outsw, algumas linhas mais abaixo, escreve uma string de dados na controladora e a 
interrupção vem da controladora de disco quando a transferência para o disco termina. No 
caso de uma leitura ou de uma escrita, at intr wait é chamada para receber a interrupção, 
por exemplo, na linha 12920, após a operação de escrita. Embora a interrupção seja esperada, 
essa função fornece uma maneira de cancelar a espera, caso ocorra um defeito e a interrupção 
nunca chegue. At intr wait também lê o registrador de status da controladora de disco e re- 
torna vários códigos. Isso é testado na linha 12933. No caso de erro na leitura ou na escrita, há 
a execução de um comando break que pula a parte do código onde os resultados são escritos 
e os ponteiros e contadores são ajustados para o próximo setor, de modo que a próxima pas- 
sagem pelo laço interno será uma nova tentativa com o mesmo setor, se for permitida outra 
tentativa. Se a controladora de disco relatar um setor danificado, w transfer terminará ime- 
diatamente. Para outros erros, um contador é incrementado e a função pode continuar caso 
max erros não tenha sido atingido. 

A próxima função que discutiremos é com. out, que envia o comando para a controlado- 
ra de disco, mas antes de examinarmos seu código, vamos ver primeiro como a controladora 
é vista pelo software. A controladora de disco é comandada por meio de um conjunto de 
registradores, os quais poderiam ser mapeados na memória em alguns sistemas, mas que em 
um computador compatível com os da IBM aparecem como portas de E/S. Vamos ver esses 
registradores e discutir alguns aspectos de como eles (e os registradores de controle de E/S 
em geral) são usados. No MINIX 3, há a complicação adicional de que os drivers são execu- 
tados em espaço de usuário e não podem executar instruções que lêem ou escrevem nesses 
registradores. Isso nos dará a oportunidade de vermos como as chamadas de núcleo são usa- 
das para contornar essa restrição. 

Os registradores usados por uma controladora de disco rígido da classe IBM-AT padrão 
aparecem na Figura 3-23. 

Mencionamos várias vezes a leitura e a escrita em portas de E/S, mas as tratamos taci- 
tamente apenas como endereços de memória. Na verdade, as portas de E/S frequentemente 
se comportam de forma diferente dos endereços de memória. Por exemplo, os registradores 
de entrada e saída que têm o mesmo endereço de porta de E/S não são os mesmos. Assim, os 
dados escritos em um endereço em particular podem não ser necessariamente recuperados 
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Registrador Função de leitura Função de escrita 
0 Dados Dados 
1 Erro Compensação prévia de escrita 
2 Contagem de setores Contagem de setores 
3 Número do Setor (0-7) Número do Setor (0-7) 
4 Cilindro Baixo (8-15) Cilindro Baixo (8-15) 
5 Cilindro Alto (16-23) Cilindro Alto (16-23) 
6 Seleção de Unidade/ Seleção de Unidade/Cabeçote (24-27) 
Cabeçote (24-27) 
7 Status Comando 


(a) 


7 6| 5| 4 3 2 1 0 
LBA 1] D| HS3 | HS2 | HS1 | HSO 


LBA: O = Modo Cilindro/Cabeçote/Setor 
(CHS — Cylinder/Head/Sector) 
1 = Modo Endereçamento de Bloco Lógico 
(LBA — Logical Block Addressing) 
D: O = unidade mestra 
1 = unidade escrava 
HSn: Modo CHS: Seleção de cabeçote no modo CHS 
Modo LBA: Bits de seleção de bloco 24 - 27 


(b) 


Figura 3-23 (a) Os registradores de controle de uma controladora de disco rígido IDE. Os 
números entre parênteses são os bits do endereço de bloco lógico selecionado em cada regis- 
trador no modo LBA. (b) Os campos do registrador Seleção de Unidade/Cabeçote. 


por uma operação de leitura subsegiiente. Por exemplo, o último endereço de registrador 
mostrado na Figura 3-23 mostra o status da controladora de disco quando é feita uma leitura. 
Esse mesmo registrador, usado em escrita, serve para executar comandos na controladora. 
Também é comum que o próprio ato da leitura ou escrita em um registrador de dispositivo 
de E/S faça uma ação ocorrer, independentemente dos detalhes dos dados transferidos. Isso 
vale para o registrador de comandos na controladora de disco AT. Quando usado, os dados 
escritos nos registradores de numeração mais baixa indicam o endereço de disco a ser lido ou 
escrito e, então, por último é escrito um código da operação. Os dados escritos no registrador 
de comandos determinam qual será a operação. O ato de escrever o código da operação no 
registrador de comandos inicia a operação. 

Também acontece que o uso de alguns registradores, ou campos nos registradores, pode 
variar com os diferentes modos de operação. No exemplo dado na figura, gravar um valor O 
ou 1 no bit LBA, o sexto bit do registrador 6, seleciona o modo CHS (Cylinder-Head-Sector) 
ou o modo LBA (Logical Base Addressing). Os dados escritos ou lidos dos registradores 3, 
4 e 5, e os quatro bits inferiores do registrador 6 são interpretados de formas diferentes, de 
acordo com a configuração do bit LBA. 
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Vamos ver agora como um comando é enviado para a controladora através da chamada 
de com out (linha 12947). Essa função é executada após a estrutura cmd (com do transfer, 
que vimos anteriormente) ter sido inicializada. Antes de alterar quaisquer registradores, o 
registrador de status é lido para determinar se a controladora não está ocupada. Isso é feito 
testando-se o bit STATUS BSY. A velocidade é importante aqui e, normalmente, a contro- 
ladora de disco está pronta ou estará pronta rapidamente; portanto, é utilizado espera ativa 
(busy waiting). Na linha 12960, w waitfor é executada para testar STATUS BSY.W waitfor 
utiliza uma chamada de núcleo para solicitar à tarefa de sistema a leitura de uma porta de E/S 
para que seja possível testar um bit no registrador de status. Um laço é executado até que o bit 
esteja pronto ou até que um tempo limite (timeout) seja atingido. O laço termina tão logo o 
disco estiver pronto. Dessa forma, o valor de retorno é disponibilizado com o mínimo atraso 
possível. Esse valor é retornado verdadeiro quando a controladora está pronta e é falso quanto 
o tempo limite (timeout) é excedido sem que ela esteja pronta. Teremos mais a dizer sobre o 
tempo limite, quando discutirmos a própria função w waitfor. 

Uma controladora pode manipular mais de uma unidade de disco; portanto, uma vez de- 
terminado que a controladora está pronta, um byte é escrito para selecionar a unidade de disco, 
o cabeçote e o modo de operação (linha 12966) e a função w waitfor é chamada novamente. 
Às vezes, uma unidade de disco não consegue executar um comando ou retornar um código 
de erro corretamente — afinal, trata-se de um dispositivo mecânico que pode travar, emperrar 
ou quebrar internamente — e, como garantia, é feita uma chamada de núcleo sys setalarm 
para que a tarefa de sistema agende uma chamada para uma rotina de despertar. Depois disso, 
o comando é executado, primeiro escrevendo todos os parâmetros nos vários registradores e, 
finalmente, escrevendo o próprio código de comando no registrador de comandos. Isso é feito 
com a chamada de núcleo sys voutb, que envia um vetor de pares (valor, endereço) para a 
tarefa de sistema. A tarefa de sistema escreve cada valor na porta de E/S especificada pelo en- 
dereço. O vetor de dados para a chamada sys voutb é construído por uma macro, pv. set, que 
é definida em include/minix/devio.h. O ato de escrever o código da operação no registrador 
de comandos faz a operação começar. Quando ela termina, uma interrupção é gerada e uma 
mensagem de notificação é enviada. Se o comando atingir o tempo limite, o alarme expirará 
e uma notificação de alarme síncrona despertará o driver de disco. 

As próximas funções são curtas. W need reset (linha 12999) é chamada quando o tem- 
po limite é atingido enquanto se espera que o disco interrompa ou se torne pronto. A ação de 
w need reset é apenas marcar a variável state de cada unidade de disco no array wini para 
forçar a inicialização no próximo acesso. 

W do close (linha 13016) faz muito pouco para um disco rígido convencional. Para 
suportar CD-ROMS é necessário código adicional. 

Com simple é usada para enviar comandos para a controladora que terminam sem uma 
fase de transferência de dados. Os comandos que caem nessa categoria incluem aqueles que 
recuperam a identificação do disco, a configuração de alguns parâmetros e a calibração. Vimos 
um exemplo de seu uso em w identify. Antes que ela seja executada, a estrutura command 
deve ser corretamente inicializada. Note que, imediatamente após a chamada de com out, é 
feita uma chamada para at intr wait. Isso culmina em uma operação receive que bloqueia até 
que chegue uma notificação significando que ocorreu uma interrupção. 

Observamos que com out faz uma chamada de núcleo sys setalarm antes de solicitar 
para que a tarefa de sistema grave os registradores que configuram e executam um comando. 
Conforme mencionamos na seção da visão geral, a próxima operação receive normalmente 
deve receber uma notificação indicando uma interrupção. Se um alarme tiver sido configura- 
do e não ocorrer nenhuma interrupção, a próxima mensagem será SYN ALARM. Nesse caso, 
a função w timeout, linha 13046, é chamada. O que precisa ser feito depende do comando 
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corrente em w command. Pode ter sobrado um tempo limite de uma operação anterior e 
w command poderá ter o valor CMD IDLE, significando que o disco completou sua ope- 
ração. Nesse caso, não há nada para fazer. Se o comando não termina e a operação é uma 
leitura ou escrita, reduzir o tamanho das requisições de E/S pode ajudar. Isso é feito em duas 
etapas, reduzindo-se o número máximo de setores que podem ser solicitados, primeiro para 
8 e depois para 1. Para todos os tempos limites, uma mensagem é impressa e w need reset é 
chamada para obrigar uma reinicialização de todas as unidades de disco na próxima tentativa 
de acesso. 

Quando é exigida uma reconfiguração, w reset (linha 13076) é chamada. Essa função 
utiliza uma função de biblioteca, tickdelay, que configura um temporizador cão de guarda e 
depois espera que ele expire. Após um atraso inicial para dar tempo para que a unidade de 
disco se recupere de operações anteriores, um bit do registrador de controle da controladora 
de disco é sinalizado — isto é, ele é posto em nível lógico 1 durante um período de tempo 
definido, e então, retornado para o nível lógico 0. Após essa operação, w waitfor é chamada 
para dar à unidade de disco um período de tempo razoável para sinalizar que está pronta. No 
caso de a reconfiguração não ser bem-sucedida, uma mensagem será impressa e um status de 
erro será retornado. 

Os comandos para o disco que envolvem a transferência de dados normalmente termi- 
nam gerando uma interrupção, a qual envia uma mensagem de volta para o driver de disco. 
Na verdade, uma interrupção é gerada para cada setor lido ou escrito. A função w intr wait 
(linha 13123) chama receive em um laço e, se for recebida uma mensagem SYN ALARM, 
w timeout será executada. O outro tipo de mensagem que essa função deve receber é 
HARD INT. Quando essa mensagem é recebida, o registrador de status é lido e ack args é 
chamada para reinicializar a interrupção. 

W intr wait não é chamada diretamente; quando é esperada uma interrupção, a função 
executada é at intr wait (linha 13152). Após uma interrupção ser recebida por at intr wait, é 
feita uma rápida verificação dos bits de status da unidade de disco. Tudo estará bem se os bits 
correspondentes a ocupado, falha de escrita e erro estiverem todos zerados. Caso contrário é 
feito um exame mais cuidadoso. Se o registrador não pode ser lido, trata-se de uma situação de 
pânico. Se o problema é um setor danificado, um erro específico é retornado; qualquer outro 
problema resulta em um código de erro genérico. Em todos os casos, o bit STATUS ADMBSY 
é ativado, para ser reativado posteriormente pelo processo que fez a chamada. 

Vimos diversos lugares onde w waitfor (linha 13177) é chamada para fazer espera ativa 
em um bit no registrador de status da controladora de disco. Isso é usado em situações nas 
quais se espera que o bit possa ser zerado no primeiro teste e é desejável um teste rápido. Para 
aumentar a velocidade, nas versões anteriores do MINIX foi usada uma macro que lia a porta 
de E/S diretamente — é claro que isso não é permitido para um driver em espaço de usuário 
no MINIX 3. A solução aqui é utilizar um laço do ... while com um mínimo de sobrecarga, 
antes que o primeiro teste seja feito. Se o bit que está sendo testado estiver zerado, haverá 
um retorno imediato de dentro do laço. Para tratar da possibilidade de falha, um tempo limite 
é implementado dentro do laço, monitorando-se os tiques de relógio. Se o tempo limite for 
excedido, w need reset será chamada. 

O parâmetro timeout usado pela função w waitfor é definido por DEF TIMEOUT TICKS, 
na linha 12228, como 300 tiques ou 5 segundos. Um parâmetro semelhante, WAKEUP (linha 
12216), usado para agendar o despertar da tarefa de relógio, é configurado com 31 segundos. 
Esses são períodos de tempo muito longos para gastar com espera ativa, quando você con- 
sidera que um processo normal recebe apenas 100 ms para executar, antes de ser removido. 
Mas esses números são baseados no padrão publicado para a interface de dispositivos de dis- 
co para computadores da classe AT, o qual diz que até 31 segundos devem ser permitidos para 
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que um disco atinja a velocidade de rotação normal. O fato é que essa é uma especificação 
para o pior caso e, na maioria dos sistemas, a aceleração para atingir a rotação só ocorre no 
momento da partida ou, possivelmente, após longos períodos de inatividade, pelo menos para 
discos rígidos. Para CD-ROMs, ou outros dispositivos que necessitem frequentemente iniciar 
sua rotação, esse pode ser um problema mais importante. 

Existem mais algumas funções em at wini.c. W geometry retorna os valores lógicos 
máximos de cilindro, cabeçote e setor do dispositivo de disco rígido selecionado. Neste caso, 
os números são os reais e não mascarados como se fossem para o driver de disco em RAM. 
W other é uma função genérica para tratar comandos não reconhecidos e para ioctl. Na ver- 
dade, ela não é usada na versão atual do MINIX 3 e provavelmente deveríamos tê-la retirado 
da listagem do Apêndice B. W hw int é chamada quando uma interrupção de hardware é 
recebida sem ser esperada. Na visão geral, mencionamos que isso pode acontecer quando um 
tempo limite expira antes que uma interrupção esperada ocorra. Isso satisfará uma operação 
receive que foi bloqueada esperando pela interrupção, mas a notificação de interrupção pode 
ser capturada por um receive subseqiiente. A única coisa a ser feita é reativar a interrupção, o 
que é feito chamando-se a função ack irgs (linha 13297). Ela varre todas as unidades de disco 
conhecidas e usa a chamada de núcleo sys irqenable para garantir que todas as interrupções 
sejam ativadas. Por último, no final de at wini.c são encontradas duas funções estranhas, 
strstatus e strerr. Essas funções utilizam as macros definidas imediatamente depois delas, 
nas linhas 13313 e 13314, para concatenar códigos de erro em strings. Essas funções não são 
utilizadas no MINIX 3, conforme descrito aqui. 


Tratamento de disquetes 


O driver de disquete é maior e mais complicado do que o driver de disco rígido. Isso pode 
parecer paradoxal, pois os mecanismos do disquete são mais simples do que os dos discos 
rígidos, mas o mecanismo mais simples tem uma controladora mais primitiva, que exige mais 
atenção do sistema operacional. Além disso, o fato da mídia ser removível acrescenta com- 
plicações. Nesta seção, descreveremos algumas coisas que um projetista deve considerar ao 
tratar com disquetes. Entretanto, não entraremos nos detalhes do código do driver de disquete 
do MINIX 3. Na verdade, não listamos o driver de disquete no Apêndice B. As partes mais 
importantes são semelhantes às do disco rígido. 

Uma das coisas com a qual não precisamos nos preocupar no driver de disquete é com 
vários tipos de controladora para suportar, como acontecia no caso do driver de disco rígido. 
Embora os disquetes de alta densidade utilizados atualmente não fossem suportados no pro- 
jeto do IBM PC original, as controladoras de disquete de todos os computadores da família 
IBM PC são suportadas por um único driver. O contraste com a situação do disco rígido 
provavelmente é devido à falta de motivação para aumentar o desempenho dos disquetes. Os 
disquetes raramente são usados como meio de armazenamento de trabalhos durante a utili- 
zação de um computador; sua velocidade e sua capacidade de armazenar dados são limitadas 
demais em comparação com as dos discos rígidos. Houve um tempo em que os disquetes 
foram importantes para a distribuição de software novo e para backup, mas como as redes e 
os dispositivos de armazenamento removíveis de maior capacidade se tornaram comuns, os 
PCs raramente vêm com unidades de disquete. 

O driver de disquete não utiliza o algoritmo SSF nem do elevador. Ele é estritamente se- 
quencial, aceitando uma requisição e executando-a antes mesmo de aceitar outra requisição. 
No projeto original do MINIX sentiu-se que, como ele se destinava para uso em computado- 
res pessoais, na maior parte do tempo haveria apenas um processo ativo. Assim, a chance de 
chegar uma requisição de disco enquanto outro processo estava sendo executado era pequena. 
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Haveria pouco a ganhar com o aumento considerável na complexidade do software que seria 
exigida para enfileirar requisições. A complexidade é ainda menos vantajosa agora, pois os 
disquetes raramente são usados para algo que não seja a transferência de dados em um siste- 
ma com disco rígido. 

Dito isso, o driver de disquete, assim como qualquer outro driver de bloco, pode tratar 
de uma requisição de E/S dispersa. Entretanto, no caso do driver de disquete, o conjunto de 
requisições é menor do que para o disco rígido, sendo limitado ao número máximo de setores 
por trilha presentes em um disquete. 

A simplicidade do hardware de disquete é responsável por algumas das complicações 
no software do driver de disquete. As unidades de disquete baratas, lentas e de baixa capa- 
cidade não justificam as sofisticadas controladoras integradas que fazem parte das unidades 
de disco rígido modernas, de modo que o software do driver precisa tratar explicitamente 
com aspectos da operação do disco que ficam ocultos na operação de uma unidade de disco 
rígido. Como exemplo de complicação causada pela simplicidade das unidades de disquete, 
considere o posicionamento do cabeçote de leitura/escrita em uma trilha específica durante 
uma operação SEEK. Nenhum disco rígido jamais exigiu que o software do driver solicitasse 
explicitamente uma operação SEEK. Para um disco rígido, a geometria do cilindro, cabeçote 
e setor visível para o programador fregiientemente não corresponde à geometria física. Na 
verdade, a geometria física pode ser bastante complicada. Normalmente, existem várias zo- 
nas (grupos de cilindros) com mais setores por trilha nas zonas externas do que nas internas. 
Entretanto, isso não é visto pelo usuário. Os discos rígidos modernos aceitam endereçamento 
de bloco lógico (LBA), o endereçamento pelo número absoluto do setor no disco, como uma 
alternativa ao endereçamento por cilindro, cabeçote e setor (CHS). Mesmo que o endereça- 
mento seja feito por cilindro, cabeçote e setor, qualquer geometria que não enderece setores 
inexistentes pode ser usada, pois a controladora integrada no disco calcula para onde vai mo- 
ver os cabeçotes de leitura/escrita e realiza uma operação de busca, quando necessário. 

Para um disquete, contudo, é necessária a programação explícita de operações SEEK. 
No caso de uma operação SEEK falhar, será necessário fornecer uma rotina para executar 
uma operação RECALIBRATE, a qual obriga os cabeçotes irem para o cilindro O. Isso torna 
possível para a controladora avançá-los até uma posição de trilha desejada, movendo os cabe- 
çotes um número conhecido de vezes. Operações semelhantes são necessárias para a unidade 
de disco rígido, é claro, mas a controladora as manipula sem orientação detalhada do software 
do driver de dispositivo. 

Algumas características de uma unidade de disquete que complicam seu driver são: 


1. Mídia removível 
2. Vários formatos de disco 


3. Controle do motor 


Algumas controladoras de disco rígido fazem preparativos para uma mídia removível, 
por exemplo, em uma unidade de CD-ROM, mas a controladora da unidade de disco ge- 
ralmente é capaz de tratar de todas as complicações sem se apoiar no software do driver 
de dispositivo. No caso de um disquete, no entanto, o suporte interno não está presente e, 
apesar disso, é mais necessário. Alguns dos usos mais comuns dos disquetes — instalar novo 
software ou fazer backup de arquivos — provavelmente exigem a troca de discos nas uni- 
dades. Será um desastre se os dados destinados a um disquete forem gravados em outro. O 
driver de dispositivo deve fazer o que puder para evitar isso. Isso nem sempre é possível, 
pois nem todo hardware de unidade de disquete permite determinar se a porta da unidade foi 
aberta desde o último acesso. Outro problema que pode ser causado pela mídia removível é 
que um sistema pode travar, caso seja feita uma tentativa de acessar uma unidade de disquete 
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que não tenha nenhum disquete inserido. Isso poderá ser resolvido se uma porta aberta puder 
ser detectada, mas como isso nem sempre é possível, alguma provisão deve ser feita para um 
tempo limite e um retorno de erro, caso uma operação em um disquete não termine em um 
tempo razoável. 

A mídia removível pode ser substituída por outra mídia e, no caso dos disquetes, exis- 
tem muitos formatos diferentes possíveis. O hardware compatível com IBM suporta tanto 
unidades de disco de 3,5 polegadas como de 5,2 polegadas e os disquetes podem ser forma- 
tados de várias maneiras, para conter desde 360 KB até 1,2 MB (em um disquete de 5,25 
polegadas) ou até 1,44 MB (em um disquete de 3,5 polegadas). 

O MINIX 3 suporta sete diferentes formatos de disquete. Duas soluções são possíveis 
para o problema causado por isso. Uma maneira é referir-se a cada formato possível como 
uma unidade de disco distinta e fornecer vários dispositivos secundários. As versões mais 
antigas do MINIX faziam isso. Foram definidos 14 dispositivos diferentes, variando de /dev/ 
pc0, um disquete de 5,25 polegadas e 360 KB na primeira unidade de disco, até /dev/PS1, um 
disquete de 3,5 polegadas e 1,44 MB, na segunda. Essa foi uma solução ruim. O MINIX 3 usa 
outro método: quando a primeira unidade de disquete é endereçada como /dev/fdO ou a segun- 
da é endereçada como /dev/fd1, o driver de disquete testa o disquete que está correntemente 
na unidade para determinar o formato. Alguns formatos têm mais cilindros e alguns têm mais 
setores por trilha do que outros formatos. A determinação do formato de um disquete é feita 
pela tentativa de ler os setores e trilhas de numeração mais alta. Por meio de um processo de 
eliminação, o formato pode ser determinado. Isso leva tempo, mas nos computadores moder- 
nos, provavelmente serão encontrados apenas disquetes de 3,5 polegadas e 1,44 MB, e esse 
formato é testado primeiro. Outro problema possível é que um disco com setores defeituosos 
poderia ser identificado de forma errada. Está disponível um programa utilitário para testar 
discos; fazer isso automaticamente no sistema operacional seria lento demais. 

A última complicação do driver de disquete é o controle do motor. Os disquetes não 
podem ser lidos nem escritos a não ser que estejam girando. Os discos rígidos são projetados 
para funcionar milhares de horas sem se desgastar, mas deixar os motores ligados o tempo 
todo faz com que a unidade de disquete e o disquete se desgastem rapidamente. Se o motor 
ainda não estiver ligado quando uma unidade de disco for acessada, será necessário executar 
um comando para iniciar a unidade de disco e depois esperar cerca de meio segundo, antes 
de tentar ler ou escrever dados. Ligar ou desligar os motores é uma operação lenta; portanto, 
o MINIX 3 deixa o motor da unidade de disco ligado por alguns segundos, depois que uma 
unidade de disco é usada. Se a unidade de disco for usada novamente dentro desse intervalo 
de tempo, o temporizador terá o tempo estendido por mais alguns segundos. Se a unidade de 
disco não for usada nesse intervalo de tempo, o motor será desligado. 


TERMINAIS 


Há décadas as pessoas têm se comunicado com os computadores usando dispositivos com- 
postos de um teclado para entrada do usuário e uma tela para saída do computador. Por muitos 
anos, esses equipamentos foram combinados em dispositivos isolados, chamados terminais, 
que eram conectados ao computador por meio de uma fiação. Os computadores de gran- 
de porte usavam esses terminais nos setores financeiro e de viagens, às vezes, ainda usam, 
normalmente conectados a um computador de grande porte por intermédio de um modem, 
particularmente quando estão distantes do computador. Entretanto, com a aparição dos com- 
putadores pessoais, o teclado e a tela se tornaram periféricos separados, em vez de um único 
dispositivo, mas eles são tão intimamente relacionados que os discutiremos juntos aqui, sob 
o título unificado “terminal”. 
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Historicamente, os terminais têm assumido diversas formas. Cabe ao driver de terminal 
ocultar todas essas diferenças, para que a parte independente de dispositivo e os programas 
de usuário não tenham de ser reescritos para cada tipo de terminal. Nas seções a seguir, segui- 
remos nossa estratégia, agora padronizada, de discutir primeiro o hardware e o software de 
terminal em geral e, depois, discutir o software do MINIX 3. 


Hardware de terminal 


Do ponto de vista do sistema operacional, os terminais podem ser divididos em três cate- 
gorias amplas, baseadas no modo como o sistema operacional se comunica com eles, assim 
como nas suas características de hardware reais. A primeira categoria consiste em terminais 
mapeados na memória, os quais são compostos de um teclado e uma tela, ambos fisicamente 
ligados ao computador. Esse modelo é usado em todos os computadores pessoais para o tecla- 
do e para o monitor. A segunda categoria consiste em terminais que fazem interface por inter- 
médio de uma linha de comunicação serial, usando o padrão RS-232, mais frequentemente, 
por meio de um modem. Esse modelo ainda é usado em alguns computadores de grande 
porte, mas os PCs também possuem interfaces de linha serial. A terceira categoria consiste 
em terminais conectados ao computador por meio de uma rede. Essa taxonomia aparece na 
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Figura 3-24 Tipos de terminal. 


Terminais mapeados em memória 


A primeira categoria de terminais da Figura 3-24 consiste nos terminais mapeados em me- 
mória. Eles são parte integrante dos próprios computadores, especialmente os computadores 
pessoais, e consistem em uma tela e um teclado. A tela mapeada em memória faz interface 
por meio de uma memória especial chamada RAM de vídeo, a qual faz parte do espaço de 
endereçamento do computador e é acessada pela CPU da mesma maneira que o restante da 
memória (veja a Figura 3-25). 

Além disso, na placa da RAM de vídeo existe um chip chamado controladora de ví- 
deo. Esse chip extrai bytes da RAM de vídeo e gera o sinal de vídeo usado para acionar o 
monitor. Normalmente, os monitores são de dois tipos: monitores de CRT ou monitores de 
tela plana. Um monitor de CRT gera um feixe de elétrons que varre a tela horizontalmente, 
gerando linhas no vídeo. Normalmente, a tela tem de 480 a 1200 linhas de cima para baixo, 
com 640 a 1920 pontos por linha. Esses pontos são chamados pixels. O sinal da controladora 
de vídeo modula a intensidade do feixe eletrônico, determinando se um pixel será claro ou 
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Figura 3-25 Os terminais mapeados em memória escrevem diretamente na RAM de vídeo. 


escuro. Os monitores em cores têm três feixes, para vermelho, verde e azul, os quais são mo- 
dulados independentemente. 

Um monitor de tela plana funciona de forma muito diferente internamente, mas um mo- 
nitor de tela plana compatível com o monitor de CRT aceita os mesmos sinais de sincronismo e 
vídeo e os utiliza para controlar um elemento de cristal líquido em cada posição de pixel. 

Em um monitor monocromático simples cada caractere ocupa um espaço de 9 pixels 
de largura por 74 pixels de altura (incluindo o espaço entre os caracteres), e ter 25 linhas de 
80 caracteres. A tela teria, então, 350 linhas de varredura de 720 pixels cada uma. Cada um 
desses quadros é redesenhado de 45 a 70 vezes por segundo. A controladora de vídeo poderia 
ser projetada para buscar os 80 primeiros caracteres da RAM de vídeo, gerar 14 linhas de var- 
redura, buscar os próximos 80 caracteres da RAM de vídeo, gerar as 14 linhas de varredura 
seguintes e assim por diante. Na verdade, a maioria busca cada caractere uma vez por linha 
de varredura, para eliminar a necessidade de buffers na controladora. Os padrões de 9 por 14 
bits dos caracteres são mantidos em uma memória ROM usada pela controladora de vídeo. 
(A memória RAM também pode ser usada para suportar fontes personalizadas.) A memória 
ROM é endereçada por meio de um endereço de 12 bits, 8 bits do código do caractere e 4 bits 
para especificar uma linha de varredura. Os 8 bits de cada byte da memória ROM controlam 
8 pixels; o 9º pixel entre os caracteres está sempre em branco. Assim, são necessárias 14 x 
80 =1120 referências de memória para a RAM de vídeo por linha de texto na tela. O mesmo 
número de referências é feito para a memória ROM do gerador de caracteres. 

O IBM PC original tinha vários modos para a tela. No mais simples, ele usava um ví- 
deo mapeado em caracteres para o console. Na Figura 3-26(a), vemos uma parte da RAM de 
vídeo. Cada caractere na tela da Figura 3-26(b) ocupava dois caracteres na memória RAM. 
O caractere de ordem inferior era o código ASCII do caractere a ser exibido. O caractere de 
ordem superior era o byte de atributo, usado para especificar a cor, vídeo reverso, piscamento 
etc. Nesse modo, a tela inteira de 25 por 80 caracteres exigia 4000 bytes de RAM de vídeo. 
Todos os vídeos modernos ainda suportam esse modo de operação. 

Os mapas de bits contemporâneos utilizam o mesmo princípio, exceto que cada pixel 
na tela é controlado individualmente. Na configuração mais simples, para um vídeo mono- 
cromático, cada pixel tem um bit correspondente na RAM de vídeo. No outro extremo, cada 
pixel é representado por um número de 24 bits, com 8 bits para vermelho, 8 para verde e 8 
para azul. Um vídeo em cores de 768 x 1024, com 24 bits por pixel, exige 2 MB of RAM para 
conter a imagem. 

Com um vídeo mapeado em memória, o teclado é completamente separado da tela. Sua 
interface pode ser por meio de uma porta serial ou paralela. A cada ação sobre uma tecla, a 
CPU é interrompida e o driver de teclado extrai o caractere digitado, lendo uma porta de E/S. 

Em um PC, o teclado contém um microprocessador incorporado que se comunica, por 
meio de uma porta serial especializada, com um chip de controladora na placa principal. É ge- 
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Figura 3-26 (a) Um exemplo de RAM de vídeo para o monitor monocrático da IBM. Os x 
são bytes de atributo. (b) A tela correspondente. 


rada uma interrupção quando uma tecla é pressionada e também quando uma tecla é liberada. 
Além disso, o hardware de teclado fornece apenas o número da tecla e não o código ASCII. 
Quando a tecla A é pressionada, o código de tecla (30) é colocado em um registrador de E/S. 
Cabe ao driver determinar se é minúscula, maiúscula, CTRL-A, ALT-A, CTRL-ALT-A ou al- 
guma outra combinação. Como o driver pode identificar quais teclas foram pressionadas, mas 
ainda não liberadas (por exemplo, shift), ele tem informações suficientes para fazer o trabalho. 
Embora essa interface de teclado coloque toda a carga sobre o software, ela é extremamente 
flexível. Por exemplo, os programas de usuário podem estar interessados em saber se um 
algarismo recentemente digitado veio da fileira superior de teclas ou do teclado numérico na 
lateral. Em princípio, o driver pode fornecer essa informação. 


Terminais RS-232 


Os terminais RS-232 são dispositivos que contêm um teclado e uma tela que se comunicam 
usando uma interface serial, um bit por vez (veja a Figura 3-27). Esses terminais usam um 
conector de 9 ou 25 pinos, do quais um é utilizado para transmitir dados, outro serve para 
receber dados e um pino é terra. Os outros pinos servem para várias funções de controle, 
a maioria das quais não é utilizada. Para enviar um caractere para um terminal RS-232, o 
computador deve transmiti-lo 1 bit por vez, prefixado por um bit inicial (start bit) e seguido 
de 1 ou 2 bits de parada (stop bit) para delimitar o caractere. Um bit de paridade, que fornece 
detecção de erro rudimentar, também pode ser inserido antes dos bits de parada, embora isso 
normalmente seja exigido apenas para comunicação com sistemas de computador de grande 
porte. As taxas de transmissão comuns são de 14.400 e 56.000 bits/s, sendo a primeira para 
fax e a última para dados. Os terminais R$-232 são normalmente usados para se comunicar 
com um computador remoto, usando um modem e uma linha telefônica. 

Como os computadores e os terminais trabalham internamente com caracteres inteiros, 
mas precisam se comunicar por meio de uma linha serial, um bit por vez, foram desenvolvi- 
dos chips para converter de caractere para serial e vice-versa. Eles são chamados de UART's 
(Universal Asynchronous Receiver Transmitters). As UARTSs são ligadas ao computador co- 
nectando-se placas de interface RS-232 no barramento, como ilustrado na Figura 3-27. Nos 
computadores modernos, a UART e a interface RS-232 frequentemente fazem parte do con- 
junto de chips da placa-mãe. É possível desativar a UART existente na placa para permitir o 
uso de uma placa de interface de modem conectada no barramento ou ambas também podem 
coexistir. Um modem também fornece uma UART (embora ela possa ser integrada com ou- 
tras funções em um chip de propósito geral) e o canal de comunicação é uma linha telefônica, 
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Figura 3-27 Um terminal RS-232 se comunica com um computador por meio de uma 
linha de comunicação, um bit por vez. O computador e o terminal são completamente inde- 
pendentes. 


em vez de um cabo serial. Entretanto, para o computador a UART parece a mesma, seja o 
meio um cabo serial dedicado ou uma linha telefônica. 

Os terminais R$-232 estão desaparecendo gradualmente, sendo substituídos por PCs, 
mas ainda são encontrados em sistemas de computador de grande porte mais antigos, espe- 
cialmente em aplicações bancárias, reservas de passagens aéreas e aplicações semelhantes. 
Contudo, programas de terminal que permitem a um computador remoto simular um terminal 
ainda são amplamente usados. 

Para imprimir um caractere, o driver de terminal escreve o caractere na placa da in- 
terface, onde ele é colocado no buffer e então enviado pela linha serial, um bit por vez, pela 
UART. Mesmo a 56.000 bps, leva mais de 140 microssegundos para enviar um caractere. 
Como resultado dessa baixa taxa de transmissão, o driver geralmente envia um caractere para 
a placa RS-232 e é bloqueado, esperando pela interrupção gerada pela interface, quando o 
caractere tiver sido transmitido e a UART for capaz de aceitar outro caractere. A UART pode 
enviar e receber caracteres simultaneamente, conforme indica seu nome (transmissor-recep- 
tor). Uma interrupção também é gerada quando um caractere é recebido e, normalmente, um 
pequeno número de caracteres de entrada pode ser colocado no buffer. Quando uma interrup- 
ção é recebida, o driver de terminal precisa verificar um registrador para determinar a causa 
da interrupção. Algumas placas de interface têm uma CPU e memória, e podem manipular 
várias linhas, assumindo grande parte da carga de E/S da CPU principal. 

Os terminais RS-232 podem ser subdivididos em categorias, conforme mencionado 
anteriormente. Os mais simples eram os terminais de impressão. Os caracteres digitados no 
teclado eram transmitidos para o computador e os caracteres enviados pelo computador eram 
impressos no papel. Esses terminais estão obsoletos e hoje em dia raramente são vistos. 

Os terminais de CRT “burros” funcionam da mesma maneira, exceto que utilizam uma 
tela, em vez de papel. Frequentemente, eles são chamados de ttys de tela, pois são funcional- 
mente iguais aos ttys de impressão. (O termo tty é uma abreviação de TeletypeQ), uma antiga 
empresa que foi pioneira no setor de terminais de computador; tty acabou se tornando sinôni- 
mo de terminal.) Os ttys de tela também são obsoletos. 

Os terminais de CRT “inteligentes” são, na verdade, computadores especializados em 
miniatura. Eles têm uma CPU e memória, e contêm software, normalmente na memória 
ROM. Do ponto de vista do sistema operacional, a principal diferença entre um tty de tela e 
um terminal inteligente é que este último compreende certas sequências de escape. Por exem- 
plo, enviando-se o caractere ASCII ESC (033), seguido de vários outros caracteres, é possível 
mover o cursor para qualquer posição na tela, inserir texto no meio da tela etc. 
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3.8.2 Software de terminal 


O teclado e o monitor são dispositivos quase independentes; portanto, os trataremos separa- 
damente aqui. (Eles não são completamente independentes, pois os caracteres digitados de- 
vem ser exibidos na tela.) No MINIX 3, os drivers de teclado e de tela fazem parte do mesmo 
processo; em outros sistemas, eles podem ser divididos em drivers distintos. 


Software de entrada 


A tarefa básica do driver de teclado é coletar a entrada do teclado e passá-la para os progra- 
mas de usuário quando eles lêem do terminal. Duas filosofias possíveis podem ser adotadas 
para o driver. Na primeira, a tarefa do driver é apenas aceitar entrada e passá-la para frente, 
sem modificação. Um programa que lê do terminal recebe uma seqüência bruta de códigos 
ASCII. (Fornecer aos programas de usuário os números de tecla é primitivo demais, além de 
ser altamente dependente da máquina.) 

Essa filosofia atende bem às necessidades dos editores de tela sofisticados, como o 
emacs, que permite ao usuário vincular uma ação arbitrária a qualquer caractere ou segiiên- 
cia de caracteres. Entretanto, isso significa que, se o usuário digitar dsta, em vez de data, e 
depois corrigir o erro digitando três retrocessos e ata, seguido de um enter, o programa de 
usuário receberá todos os 11 códigos ASCII digitados. 

A maioria dos programas não exige tantos detalhes. Eles querem apenas a entrada corri- 
gida e não a segiiência exata de como ela foi produzida. Essa observação leva à segunda filo- 
sofia: o driver manipula toda edição entre linhas e envia para os programas de usuário apenas 
as linhas corrigidas. A primeira filosofia é baseada em caracteres; a segunda é baseada em li- 
nhas. Originalmente, elas eram referidas como modo bruto (raw mode) e modo processado 
(cooked mode), respectivamente. O padrão POSIX usa o termo menos pitoresco modo canô- 
nico para descrever o modo baseado em linhas. Na maioria dos sistemas, o modo canônico se 
refere a uma configuração bem definida. O modo não-canônico é equivalente ao modo bruto, 
apesar de que muitos detalhes do comportamento do terminal possam ser alterados. Os siste- 
mas compatíveis com o padrão POSIX fornecem várias funções de biblioteca que suportam a 
seleção de um dos dois modos e a alteração de muitos aspectos da configuração do terminal. 
No MINIX 3, a chamada de sistema ioctl suporta essas funções. 

A primeira tarefa do driver de teclado é coletar caracteres. Se cada pressionamento de 
tecla causa uma interrupção, o driver pode obter o caractere durante a interrupção. Se as in- 
terrupções são transformadas em mensagens pelo software de baixo nível, é possível colocar 
na mensagem o caractere recentemente obtido. Como alternativa, ele pode ser colocado em 
um pequeno buffer na memória e a mensagem pode ser usada para informar ao driver que 
algo chegou. Esta última estratégia será mais segura se uma mensagem só puder ser enviada 
para um processo que esteja esperando e houver alguma chance de que o driver de teclado 
ainda possa estar ocupado com o caractere anterior. 

Uma vez que o driver tenha recebido o caractere, ele deve começar a processá-lo. Se 
o teclado enviar os números de tecla, em vez dos códigos de caractere usados pelo software 
aplicativo, então o driver deverá fazer a conversão entre os códigos, usando uma tabela. Nem 
todos os computadores IBM compatíveis utilizam numeração de teclas padrão; portanto, se 
o driver quiser suportar essas máquinas, deverá fazer o mapeamento dos diferentes teclados 
com diferentes tabelas. Uma estratégia simples é compilar uma tabela que faça o mapea- 
mento entre os códigos fornecidos pelo teclado e os códigos ASCII (American Standard Code 
Jor Information Interchange) no driver de teclado, mas isso é insatisfatório para usuários de 
idiomas que não sejam o inglês. Os teclados são organizados de formas diferentes em cada 
país e o conjunto de caracteres ASCII não é adequado nem mesmo para a maioria das pessoas 
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do hemisfério Ocidental, onde os idiomas espanhol, português e francês precisam de carac- 
teres acentuados e sinais de pontuação não utilizados no inglês. Para atender à necessidade 
de flexibilidade nos layouts de teclado a fim de prover suporte a diferentes idiomas, muitos 
sistemas operacionais fornecem mapas de teclado ou páginas de código carregáveis, que 
tornam possível escolher o mapeamento entre os códigos de teclado e os códigos enviados 
para o aplicativo, seja quando o sistema é inicializado ou depois. 

Se o terminal está no modo canônico, isto é, processado, os caracteres são armazenados 
até que uma linha inteira tenha sido acumulada, pois o usuário pode, subsequentemente, de- 
cidir apagar parte dela. Mesmo que o terminal esteja no modo bruto, o programa pode ainda 
não ter solicitado entrada; portanto, os caracteres devem ser colocados no buffer para permitir 
digitação antecipada. (Os projetistas que não permitem os usuários digitarem com bastante 
antecedência deveriam ser cobertos com alcatrão e penas ou, pior ainda, deveriam ser obriga- 
dos a utilizar seus próprios sistemas.) 

Duas estratégias para colocar caracteres em buffer são comuns. Na primeira, o driver 
contém um conjunto único de buffers (pool), cada buffer contendo, talvez, 10 caracteres. A 
cada terminal está associada uma estrutura de dados, a qual contém, dentre outros itens, um 
ponteiro para o encadeamento de buffers para a entrada coletada desse terminal. À medida 
que mais caracteres são digitados, mais buffers são adquiridos e incluídos no encadeamento. 
Quando os caracteres são passados para o programa de usuário, os buffers são removidos e 
colocados de volta no pool. 

A outra estratégia é utilizar os buffers diretamente na própria estrutura de dados do ter- 
minal, sem nenhum pool de buffers. Como é comum os usuários digitarem um comando que 
levará algum tempo (digamos, uma compilação) e depois digitarem algumas linhas anteci- 
padamente, por segurança o driver deve alocar algo em torno de 200 caracteres por terminal. 
Em um sistema grande de compartilhamento de tempo, com 100 terminais, alocar 20K o 
tempo todo para digitação antecipada é claramente exagerado; portanto, provavelmente será 
suficiente um pool de buffers, com espaço de, talvez, 5K. Por outro lado, um buffer dedicado 
por terminal torna o driver mais simples (não há gerenciamento de lista encadeada) e seria 
preferível em computadores pessoais com apenas um ou dois terminais. A Figura 3-28 mostra 
a diferença entre esses dois métodos. 


Estrutura de Estrutura de 
dados do terminal dados do terminal 
Pool central 
Terminal de buffers Terminal 

0 

1 0 

2 buffer do 
terminal O 

3 


buffer do 
terminal 1 


(a) (b) 
Figura 3-28 (a) Pool central de buffers. (b) Buffer dedicado para cada terminal. 
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Embora o teclado e o monitor sejam dispositivos logicamente separados, muitos usuá- 
rios cresceram acostumados a ver os caracteres que acabaram de digitar aparecerem na tela. 
Alguns terminais (mais antigos) obedecem, exibindo automaticamente (no hardware) o que 
foi digitado, o que não apenas é um incômodo quando senhas estão sendo digitadas, mas 
também limita muito a flexibilidade dos editores e outros programas sofisticados. Felizmen- 
te, os teclados de PC não exibem nada quando as teclas são pressionadas. Portanto, cabe ao 
software exibir a entrada. Esse processo é chamado de eco (echo). 

O eco é complicado pelo fato de que um programa pode estar escrevendo na tela en- 
quanto o usuário está digitando. No mínimo, o driver de teclado precisa descobrir onde vai 
colocar a nova entrada sem que ela seja sobrescrita pela saída do programa. 

O eco também fica complicado quando mais de 80 caracteres são digitados em um 
terminal com linhas de 80 caracteres. Dependendo do aplicativo, pode ser apropriada uma 
mudança automática para a próxima linha. Alguns drivers apenas truncam as linhas em 80 
caracteres, jogando fora todos os caracteres além da coluna 80. 

Outro problema é o tratamento da tabulação. Todos os teclados têm uma tecla de tabula- 
ção, mas os monitores só podem manipular a tabulação na saída. Cabe ao driver calcular onde 
o cursor está localizado correntemente, levando em conta a saída dos programas e a saída do 
eco, e calcular o número correto de espaços a serem deixados. 

Agora, chegamos ao problema da equivalência de dispositivo. Logicamente, no final de 
uma linha de texto, queremos um retorno de carro (carriage return) para mover o cursor de 
volta para a coluna 1 e um avanço de linha (line feed) para ir para a próxima linha. Exigir que 
os usuários digitem os dois caracteres no final de cada linha não daria certo (embora alguns 
terminais antigos tivessem uma tecla que gerava ambos, com uma chance de 50% de fazer 
isso na ordem exigida pelo software). Cabia (e ainda cabe) ao driver converter a entrada para 
o formato interno padrão utilizado pelo sistema operacional. 

Se a forma padrão é apenas armazenar um avanço de linha (a convenção no UNIX e em 
todos os seus descendentes), o retorno de carro deve ser transformado em avanço de linha. Se 
o formato interno é armazenar ambos, então o driver deve gerar um avanço de linha quando 
receber um retorno de carro e ao receber um avanço de linha gerar um retorno de carro. In- 
dependente da convenção interna, o terminal pode exigir o eco tanto de um avanço de linha 
como de um retorno de carro para atualizar a tela corretamente. Como um computador grande 
pode ter uma grande variedade de terminais diferentes ligados a ele, fica por conta do driver 
de teclado converter todas as diferentes combinações de retorno de carro/avanço de linha para 
o padrão interno do sistema e providenciar para que todo eco seja feito corretamente. 

Um problema relacionado é a sincronização de retorno de carro e avanços de linha. Em 
alguns terminais, pode demorar mais para exibir um retorno de carro ou um avanço de linha 
do que uma letra ou um número. Se o microprocessador que está dentro do terminal precisar 
copiar um grande bloco de texto para fazer a tela rolar, então os avanços de linha podem ser 
lentos. Se um cabeçote de impressão mecânico tiver de voltar para a margem esquerda do 
papel, os retornos de carro podem ser lentos. Nos dois casos, cabe ao driver inserir caracte- 
res de preenchimento (caracteres nulos fictícios) no fluxo de saída ou apenas interromper a 
saída por um tempo longo o suficiente para que o terminal possa alcançá-lo. A quantidade de 
tempo de espera freqientemente está relacionada à velocidade do terminal; por exemplo, em 
4800 bps ou menos, nenhum atraso pode ser necessário, mas em 9600 bps ou mais, pode ser 
exigido um caractere de preenchimento. Os terminais com tabulações de hardware, especial- 
mente os de impressão, também podem exigir um atraso após uma tabulação. 

Ao se operar no modo canônico, vários caracteres de entrada têm significados especiais. 
A Figura 3-29 mostra todos os caracteres especiais exigidos pelo POSIX e os caracteres adi- 
cionais reconhecidos pelo MINIX 3. Os padrões são todos caracteres de controle que não de- 
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vem entrar em conflito com entrada de texto ou com códigos utilizados pelos programas, mas 
todos, exceto os dois últimos, podem ser alterados usando-se o comando stty, se desejado. As 
versões mais antigas do UNIX usavam padrões diferentes para muitos deles. 


Caractere | Nome POSIX | Comentário 
CTRL-D EOF Fim de arquivo 

EOL Fim de linha (não definido) 
CTRL-H ERASE Retrocede um caractere (backspace) 
CTRL-C INTR Interrompe processo (SIGINT) 
CTRL-U KILL Apaga a linha inteira que está sendo digitada 
CTRL-\ QUIT Força um core dump (SIGQUIT) 
CTRL-Z SUSP Suspende (ignorado pelo MINIX) 
CTRL-Q START Inicia saída 
CTRL-S STOP Interrompe saída 
CTRL-R REPRINT Exibe a entrada novamente (extensão do MINIX) 
CTRL-V LNEXT Literal seguinte (extensão do MINIX) 
CTRL-O DISCARD Descarta saída (extensão do MINIX) 
CTRL-M CR Retorno de carro (inalterável) 
CTRL-J NL Avanço de linha (inalterável) 


Figura 3-29 Caracteres tratados de forma especial no modo canônico. 


O caractere ERASE permite que o usuário apague o caractere que acabou de digitar. No 
MINIX 3, é o retrocesso (CTRL-H). Ele não é adicionado na fila de caracteres, mas, em vez 
disso, remove o caractere anterior da fila. Ele deve ser ecoado como uma segiiência de três 
caracteres (retrocesso, espaço e retrocesso) para remover o caractere anterior da tela. Se o 
caractere anterior foi uma tabulação, apagá-la exige monitorar onde o cursor estava antes da 
tabulação. Na maioria dos sistemas, o retrocesso só apaga caracteres na linha corrente. Ele 
não apaga um retorno de carro e volta para a linha anterior. 

Quando o usuário observa um erro no início da linha que está sendo digitada, frequente- 
mente é conveniente apagar a linha inteira e começar de novo. O caractere KILL (no MINIX 
3, CTRL-U) apaga a linha inteira. O MINIX 3 faz a linha apagada desaparecer da tela, mas 
alguns sistemas a ecoam, com mais um retorno de carro e um avanço de linha, pois alguns 
usuários gostam de ver a linha antiga. Consegiientemente, o modo de ecoar KILL é uma ques- 
tão de gosto. Assim como no caso de ERASE, normalmente não é possível retroceder além 
da linha corrente. Quando um bloco de caracteres é eliminado, pode valer a pena (ou não) o 
driver retornar buffers para o pool, se for o caso. 

Às vezes, os caracteres ERASE ou KILL devem ser inseridos como dados normais. O 
caractere LNEXT serve como caractere de escape. No MINIX 3, CTRL-V é o padrão. Como 
um exemplo, os sistemas UNIX mais antigos normalmente usavam o sinal @ para KILL, mas 
o sistema de correio eletrônico da Internet utiliza endereços da forma linda Ocs.washington. 
edu. Alguém que se sinta mais confortável com as convenções mais antigas pode redefinir 
KILL como O, mas então precisará digitar um sinal O literalmente para endereçar e-mail. 
Isso pode ser feito digitando-se CTRL-V @. A combinação CTRL-V em si pode ser inserida 
literalmente, digitando-se CTRL-V CTRL-V. Após ver uma combinação CTRL-V, o driver 
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ativa um flag informando que o próximo caractere está isento de processamento especial. O 
caractere LNEXT em si não é inserido na fila de caracteres. 

Para permitir que os usuários impeçam a rolagem da imagem de tela para fora do campo 
de visão, são fornecidos códigos de controle para congelar a tela e reiniciá-la posteriormente. 
No MINIX 3, esses códigos são STOP (CTRL-S) e START (CTRL-Q), respectivamente. Eles 
não são armazenados, mas utilizados para ativar e desativar um flag na estrutura de dados do 
terminal. Ao se executar uma operação de saída, o flag é inspecionado. Se ele estiver ativado 
nenhuma saída ocorrerá. Normalmente, o eco também é suprimido junto com a saída do 
programa. 

Frequentemente é necessário eliminar um programa descontrolado que está sendo de- 
purado. Os caracteres INTR (CTRL-C) e QUIT (CTRLA) podem ser usados para isso. No MI- 
NIX 3, CTRL-C envia o sinal SIGINT para todos os processos iniciados a partir do terminal. 
Implementar CTRL-C pode ser muito complicado. O mais difícil é enviar as informações do 
driver para a parte do sistema que trata de sinais, a qual, afinal, não solicitou essas informa- 
ções. CTRLA é semelhante à CTRL-C, exceto que envia o sinal SIGQUIT, que força um core 
dump caso não seja capturado ou ignorado. 

Quando uma dessas combinações de tecla é pressionada, o driver deve ecoar um retor- 
no de carro e um avanço de linha, e descartar toda a entrada acumulada para possibilitar um 
início atualizado. Historicamente, DEL era comumente usada como valor padrão para INTR 
em muitos sistemas UNIX. Como muitos programas utilizam DEL ou a tecla de retrocesso 
indistintamente para edição, CTRL-C é preferido. 

Outro caractere especial é EOF (CTRL-D), que no MINIX 3 faz com que todas as re- 
quisições de leitura pendentes para o terminal sejam atendidos com o que estiver disponível 
no buffer, mesmo que o buffer esteja vazio. Digitar CTRL-D no início de uma linha faz o 
programa obter uma leitura de O bytes, o que é convencionalmente interpretado como fim de 
arquivo e faz a maioria dos programas agir da mesma maneira como se estivessem vendo o 
fim de um arquivo de entrada. 

Alguns drivers de terminal permitem uma edição entre linhas muito mais interessante 
do que esboçamos aqui. Eles têm caracteres de controle especiais para apagar uma palavra, 
pular caracteres ou palavras para trás ou para frente, ir para o início ou para o final da linha 
que está sendo digitada etc. Adicionar todas essas funções no driver de terminal o torna muito 
maior e, ademais, é um desperdício ao se utilizar editores de tela que, de qualquer forma, 
trabalham no modo bruto. 

Para permitir que os programas controlem parâmetros de terminal, o POSIX exige que 
várias funções estejam disponíveis na biblioteca padrão, das quais as mais importantes são 
tcgetattr e tcsetattr. Tcgetattr recupera uma cópia da estrutura mostrada na Figura 3-30, a 
estrutura termios, que contém todas as informações necessárias para alterar caracteres espe- 
ciais, configurar modos e modificar outras características de um terminal. Um programa pode 
examinar as configurações correntes e modificá-las conforme for desejado. Então, tcsetattr 
escreve a estrutura novamente no driver de terminal. 

O padrão POSIX não especifica se seus requisitos devem ser implementados por meio 
de funções de biblioteca ou de chamadas de sistema. O MINIX 3 fornece uma chamada de 
sistema, ioctl, chamada por 


iocti(file descriptor, request, argp); 


que é usada para examinar e modificar as configurações de muitos dispositivos de E/S. Essa 
chamada é usada para implementar as funções tcgetattr e tcsetattr. A variável request espe- 
cifica se a estrutura termios deve ser lida ou escrita e, neste último caso, se a requisição deve 
entrar em vigor imediatamente ou se deve ser adiada até que toda saída correntemente enfilei- 
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struct termios ( 


tcflag tc iflag; /* modos de entrada */ 

tcflag tc oflag; /* modos de saída */ 

tcflag tc cflag; /* modos de controle */ 

tcflag tc lflag; /* modos locais */ 

speed tc ispeed; /* velocidade de entrada */ 

speed tc ospeed; /* velocidade de saída */ 

cc tc ce|NCCS]; /* caracteres de controle */ 
x 
Figura 3-30 A estrutura termios. No MINIX 3, tc flag té um short, speed téumintecc t 
é um char. 


rada tenha terminada. A variável argp é um ponteiro para uma estrutura termios no programa 
que fez a chamada. Essa escolha em particular de comunicação entre programa e driver foi 
feita devido a sua compatibilidade com o UNIX, e não por sua beleza inerente. 

Algumas notas sobre a estrutura termios são necessárias. Os quatro flag proporcionam 
muita flexibilidade. Os bits individuais em c iflag controlam as várias maneiras pela qual 
uma entrada é manipulada. Por exemplo, o bit ICRNL faz os caracteres CR serem convertidos 
em NL na entrada. Esse flag é ativado por padrão no MINIX 3. C oflag contém os bits que 
afetam o processamento da saída. Por exemplo, o bit OPOST ativa o processamento da saída. 
Ele, e o bit ONLCR, são quem fazem com que caracteres NL na saída sejam convertidos em 
uma segiiência CR NL. Ambos são ativados por padrão no MINIX 3. C cflag é a palavra dos 
flags de controle. As configurações padrão do MINIX 3 permitem que se receba caracteres 
em 8 bits e, caso um usuário se desconecte da linha serial, que se desligue o modem. € lflag é 
o campo de flags de modo local. Um bit, ECHO, ativa o eco (isso pode ser desativado durante 
um login para proporcionar segurança na digitação de uma senha). Seu bit mais importante 
é ICANON, que ativa o modo canônico. Com o bit ICANON desativado, existem várias pos- 
sibilidades. Se todas as outras configurações forem deixadas em seus padrões, entra-se em 
um modo idêntico ao modo cbreak tradicional. Nesse modo, os caracteres são passados para 
o programa sem esperar por uma linha completa, mas os caracteres INTR, QUIT, START e 
STOP mantêm seus efeitos. Entretanto, todos eles podem ser desativados pela reconfiguração 
dos bits nos flags, para produzir o equivalente ao modo bruto tradicional. 

Os vários caracteres especiais que podem ser alterados, incluindo os que são extensões 
do MINIX 3, são mantidos no array c cc. Esse array também contém dois parâmetros que são 
usados no modo não-canônico. A quantidade MIN, armazenada em c cc[VMIN], especifica o 
número mínimo de caracteres que devem ser recebidos para satisfazer uma chamada de read. 
A quantidade TIME em c cc[VTIME] configura um limite de tempo para tais chamadas. MIN 
e TIME interagem como se vê na Figura 3-31. Nela, está ilustrada uma chamada que solicita N 
bytes. Com TIME = 0 e MIN = 1, o comportamento é semelhante ao modo bruto tradicional. 


TIME = 0 TIME > O 


MIN =0 | Retorna imediatamente com o | O temporizador inicia imediatamente. 
que estiver disponível, de 0 a Retorna com o primeiro byte fornecido ou 


N bytes com 0 bytes, após o tempo limite 

MIN >0 | Retorna com pelo menos MIN | O temporizador entre bytes inicia após o 
e até N bytes. Possível bloco primeiro byte. Retorna N bytes, se recebido 
indefinido. durante o tempo limite, ou pelo menos 1 byte 


no tempo limite. Possível bloco indefinido. 


Figura 3-31 MIN e TIME determinam quando uma chamada para ler retorna no modo não- 
canônico. N é o número de bytes solicitados. 


CAPÍTULO 3 e ENTRADA/SAÍDA 299 


Software de saída 


A saída é mais simples do que a entrada, mas os drivers para terminais RS-232 são radicalmen- 
te diferentes dos drivers para terminais mapeados em memória. O método comumente usado 
para terminais RS-232 é ter buffers de saída associados a cada terminal. Os buffers podem ser 
provenientes do mesmo pool que os buffers de entrada ou serem dedicados, como acontece 
com a entrada. Quando os programas escrevem no terminal, a saída é inicialmente copiada nos 
buffers, assim como a saída de eco. Após toda saída ter sido copiada nos buffers (ou os buffers 
estarem cheios), o primeiro caractere aparece na saída e o driver entra em repouso. Quando 
ocorre a interrupção, o próximo caractere é gerado na saída e assim por diante. 

Com terminais mapeados em memória, é possível um esquema mais simples. Os ca- 
racteres a serem impressos são extraídos, um por vez, do espaço de usuário e colocados 
diretamente na RAM de vídeo. Com terminais RS-232, cada caractere a ser gerado na saída é 
apenas colocado na linha para o terminal. Com mapeamento em memória, alguns caracteres 
exigem tratamento especial, dentre eles, o retrocesso, o retorno de carro, o avanço de linha e o 
sinal audível (CTRL-G). Um driver para um terminal mapeado em memória deve monitorar a 
posição corrente na RAM de vídeo, para que os caracteres imprimíveis possam ser colocados 
lá e a posição corrente, avançada. O retrocesso, retorno de carro e avanço de linha, todos eles 
exigem essa posição para serem atualizados corretamente. As tabulações também exigem 
processamento especial. 

Em particular, quando um avanço de linha é gerado na linha inferior da tela, a tela 
deve rolar. Para ver como a rolagem funciona, observe a Figura 3-26. Se a controladora de 
vídeo sempre começasse lendo a memória RAM em 0xB0000, a única maneira de rolar a tela 
no modo de caractere seria copiar 24 x 80 caracteres (cada caractere exigindo 2 bytes) de 
0xBOOAO a 0xB0000, algo demorado. No modo de mapa de bits, seria ainda pior. 

Felizmente, o hardware normalmente dá alguma ajuda aqui. A maioria das controladoras 
de vídeo contém um registrador que determina onde, na RAM de vídeo, vai começar a busca 
de bytes para a linha superior da tela. Configurando-se esse registrador de modo que aponte 
para 0xB00A0, em vez de 0xB0000, a linha que anteriormente era a de número dois se move 
para o topo e a tela inteira rola uma linha para cima. A única outra coisa que o driver deve fazer 
é copiar o que for necessário na nova linha inferior. Quando a controladora de vídeo chega ao 
início da memória RAM, ela apenas circula e continua a buscar bytes a partir do endereço mais 
baixo. Uma ajuda de hardware semelhante é fornecida no modo de mapa de bits. 

Outro problema que o driver deve tratar em um terminal mapeado em memória é o posi- 
cionamento do cursor. Novamente, o hardware fornece uma ajuda na forma de um registrador 
que informa para onde o cursor vai. Finalmente, há o problema do sinal audível. Ele soa por 
meio da saída de uma onda senoidal ou quadrada no alto-falante, uma parte do computador 
bem distinta da RAM de vídeo. 

Os editores de tela e muitos outros programas sofisticados precisam atualizar a tela de 
maneiras mais complexas do que apenas rolando texto na parte inferior do vídeo. Para aten- 
dê-los, muitos drivers de terminal suportam uma variedade de segiiências de escape. Embora 
alguns terminais suportem conjuntos de sequências de escape idiossincráticos, é vantajoso 
ter um padrão para facilitar a adaptação do software de um sistema para outro. O American 
National Standards Institute (ANSI) definiu um conjunto de segiiências de escape padrão 
e o MINIX 3 suporta um subconjunto das sequências ANSI, mostrado na Figura 3-32, que 
é adequado para muitas operações comuns. Quando o driver vê o caractere que inicia as 
sequências de escape, ele ativa um flag e espera até que o restante da sequência de escape 
chegue. Quando tudo tiver chegado, o driver deverá executar a sequência no software. Inserir 
e excluir texto exige mover blocos de caracteres na RAM de vídeo. Para isso o hardware não 
fornece nenhum auxílio. 
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3.8.3 


Seqiiência de escape Significado 

ESC[nA Move n linhas para cima 

ESC [nB Move n linhas para baixo 

ESC [nC Move n espaços para a direita 

ESC[nD Move n espaços para a esquerda 

ESC [m; nH Move o cursor para (y = m, x = n) 

ESCIsJ Limpa a tela a partir do cursor (O até o final, 1 a partir do 
início, 2 tudo) 

ESC [sk Limpa a linha a partir do cursor (O até o final, 1 a partir do 
início, 2 tudo) 

ESC [nL Insere n linhas no cursor 

ESC[nM Exclui n linhas no cursor 

ESC [nP Exclui n caracteres no cursor 

ESC[n O Insere n caracteres no cursor 

ESC [nm Ativa estilo de exibição n (0=normal, 4=negyrito, 
5=intermitente, 7=inverso) 

ESCM Rola a tela para trás se o cursor estiver na linha superior 


Figura 3-32 As segiiências de escape ANSI aceitas pelo driver de terminal na saída. ESC 
denota o caractere de escape ASCII (0x1B) e n, m e s são parâmetros numéricos opcionais. 


Visão geral do driver de terminal no MINIX 3 


O driver de terminal está contido em quatro arquivos em C (seis, se o suporte para RS-232 e 
pseudoterminal estiver ativo) e, juntos, eles constituem de longe o maior driver no MINIX 3. 
O tamanho do driver de terminal é parcialmente explicado pela observação de que o driver 
manipula o teclado e o monitor, cada um dos quais por si só é um dispositivo complicado, 
assim como dois outros tipos de terminais opcionais. Apesar disso, surpreende a maioria das 
pessoas saber que a E/S de terminal exige 30 vezes mais código do que o escalonador. (Essa 
sensação é reforçada vendo-se os numerosos livros sobre sistemas operacionais que dedicam 
30 vezes mais espaço para o escalonamento do que para toda E/S combinada.) 
O driver de terminal aceita mais de dez tipos de mensagem. Os mais importantes são: 


1. Ler terminal (a partir do sistema de arquivos, em nome de um processo de usuá- 
rio). 

2. Escrever no terminal (a partir do sistema de arquivos, em nome de um processo de 
usuário). 

3. Configurar parâmetros de terminal para ioctl (a partir do sistema de arquivos, em 
nome de um processo de usuário). 


4. Sinalizar ocorrência de uma interrupção de teclado (tecla pressionada ou liberada). 


5. Cancelar uma requisição anterior (a partir do sistema de arquivos, quando ocorre 
um sinal). 


6. Abrir um dispositivo. 


7. Fechar um dispositivo. 
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Outros tipos de mensagem são usados para propósitos especiais, como a geração de 
telas de diagnóstico quando teclas de função são pressionadas ou a ativação de dumps em 
situações de pânico. 

As mensagens usadas para leitura e escrita têm o mesmo formato, como se vê na Figura 
3-17, exceto que nenhum campo POSITION é necessário. No caso de um disco, o programa 
tem de especificar qual bloco deseja ler. No caso de um teclado, não há escolha: o programa 
sempre recebe o próximo caractere digitado. Os teclados não aceitam buscas. 

As funções do POSIX tcgetattr e tcgetattr, usadas para examinar e modificar atributos 
(propriedades) do terminal, são suportadas pela chamada de sistema ioctl. Uma boa prática 
de programação é usar essas funções e outras em include/termios.h e deixar para a biblioteca 
da linguagem C converter chamadas de biblioteca em chamadas de sistema ioctl. Entretanto, 
existem algumas operações de controle necessárias para o MINIX 3 que não são fornecidas 
no POSIX para, por exemplo, carregar um mapa de teclado alternativo e, para isso, o progra- 
mador deve usar ioctl explicitamente. 

A mensagem enviada para o driver por uma chamada de sistema ioctl contém um có- 
digo de requisição de função e um ponteiro. Para a função tcsetattr, uma chamada de ioctl é 
feita com um tipo de requisição TCSETS, TCSETSW ou TCSETSF e um ponteiro para uma 
estrutura termios, como aquela mostrada na Figura 3-30. Todas essas chamadas substituem 
o conjunto de atributos corrente por um novo conjunto, sendo que as diferenças são que uma 
requisição TCSETS entra em vigor imediatamente, uma requisição TCSETSW não entra em 
vigor até que toda saída tenha sido transmitida e uma requisição TCSETSF espera que a saída 
termine e descarta toda entrada que ainda não tiver sido lida. Tcgetattr é transformada em 
uma chamada de ioctl com um tipo de requisição TCGETS e retorna uma estrutura termios 
preenchida para o processo que fez a chamada, de modo que o estado corrente de um dispo- 
sitivo possa ser examinado. As chamadas de ioctl que não correspondem às funções definidas 
pelo POSIX, como a requisição KIOCSMAP, usado para carregar um novo mapa de teclado, 
passam ponteiros para outros tipos de estruturas; neste caso, para uma estrutura keymap t, 
que tem 1536 bytes (códigos de 16 bits para 128 teclas por 6 modificadores). A Figura 3-39 
resume o modo como as chamadas do padrão POSIX são convertidas em chamadas de siste- 
ma ioctl. 

O driver de terminal usa uma única estrutura de dados principal, tty table, que é um ar- 
ray de estruturas tty, uma por terminal. Um PC padrão tem apenas um teclado e um monitor, 
mas o MINIX 3 pode suportar até oito terminais virtuais, dependendo da quantidade de me- 
mória na placa adaptadora de vídeo. Isso permite à pessoa que estiver no console se conectar 
várias vezes, trocando a saída de vídeo e a entrada de teclado de um “usuário” para outro. 
Com dois consoles virtuais, pressionar ALT-F2 seleciona o segundo e ALT-FI retorna ao pri- 
meiro (ALT e as teclas de seta também podem ser usadas). Além disso, linhas seriais podem 
suportar dois usuários em locais remotos, conectados por cabo RS-232 ou modem, e pseu- 
doterminais podem suportar usuários conectados por meio de uma rede. O driver foi escrito 
para tornar fácil adicionar mais terminais. A configuração padrão ilustrada no código-fonte 
deste texto tem dois consoles virtuais, com linhas seriais e pseudoterminais desativados. 

Cada estrutura tty em tty table controla a entrada e a saída. Para a entrada, ela contém 
uma fila de todos os caracteres que foram digitados, mas ainda não lidos pelo programa, in- 
formações sobre requisições para ler caracteres que ainda não foram recebidos e informações 
sobre tempo limite, de modo que a entrada pode ser solicitada sem que o driver bloqueie 
permanentemente, caso nenhum caractere seja digitado. Para a saída, ela contém os parâme- 
tros das requisições de escrita que ainda não terminaram. Outros campos contêm diversas 
variáveis gerais, como a estrutura termios discutida anteriormente, as quais afetam muitas 
propriedades da entrada e da saída. Também existe um campo na estrutura tty para apontar 
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para informações necessárias para uma classe em particular de dispositivos, mas que não são 
necessárias na entrada tty table de cada dispositivo. Por exemplo, a parte dependente de har- 
dware do driver de console precisa da posição corrente na tela e na RAM de vídeo, e do byte 
de atributo corrente do vídeo, mas essas informações não são necessárias para suportar uma 
linha RS-232. As estruturas de dados privativas de cada tipo de dispositivo também alojam 
os buffers que recebem entradas das rotinas do serviço de interrupção. Os dispositivos lentos, 
como os teclados, não precisam de buffers tão grandes quanto aqueles necessários para dis- 
positivos rápidos. 


Entrada de terminal 


Para entendermos melhor o funcionamento do driver, vamos ver primeiro como os caracteres 
digitados no teclado passam pelo sistema e vão para o programa que os necessita. Embora 
esta seção se destine a ser uma visão geral, utilizaremos referências de número de linha para 
ajudar o leitor a encontrar cada função usada. Talvez você ache uma montanha-russa estudar 
código que aparece em tty.c, keyboard.c e console.c, todos os quais são arquivos grandes. 

Quando um usuário se conecta no console do sistema, um shell é criado para ele, com 
/dev/console como entrada padrão, saída padrão e erro padrão. O shell inicia e tenta ler a 
entrada padrão chamando a função de biblioteca read. Essa função envia para o sistema de 
arquivos uma mensagem contendo o descritor de arquivo, o endereço do buffer e uma quanti- 
dade. Essa mensagem é mostrada como (1) na Figura 3-33. Após enviar a mensagem, o shell 
é bloqueado, esperando pela resposta. (Os processos de usuário executam apenas a primitiva 
sendrec, que combina uma operação send com uma operação receive do processo para o qual 
foi enviada.) 

O sistema de arquivos recebe a mensagem e localiza o i-node correspondente ao descri- 
tor de arquivo especificado. Esse i-node é para o arquivo de caractere especial /dev/console e 
contém os números principal e secundário de dispositivo para o terminal. O tipo de dispositi- 
vo principal para terminais é 4; para o console, o número secundário do dispositivo é 0. 

O sistema de arquivos indexa em seu mapa de dispositivos, dmap, para encontrar o 
número do driver de terminal, TTY. Então, ele envia uma mensagem para TTY, mostrada 
como (2) na Figura 3-33. Normalmente, o usuário não terá digitado nada ainda, de modo 
que o driver de terminal não poderá atender a requisição. Ele envia uma resposta de volta 
imediatamente, para desbloquear o sistema de arquivos e relatar que nenhum caractere está 
disponível, o que aparece como (3) na figura. O sistema de arquivos registra o fato de que um 
processo está esperando uma entrada do terminal (isto é, do teclado) na estrutura do console 
em tty table e, em seguida, passa a trabalhar na próxima requisição. O shell do usuário per- 
manece bloqueado, é claro, até que os caracteres solicitados cheguem. 

Quando um caractere é digitado no teclado, isso causa duas interrupções, uma quando 
a tecla é pressionada e outra quando ela é liberada. Um ponto importante é que o teclado de 
um PC não gera códigos ASCI; cada tecla gera um código de varredura (scan code) quando 
pressionada e um código diferente, quando liberada. Os 7 bits inferiores dos códigos de pres- 
sionamento e de liberação de teclas são idênticos. A diferença está no bit mais significativo, 
que é O quando a tecla é pressionada e 1 quando ela é liberada. Isso também se aplica às teclas 
modificadoras, como CTRL e SHIFT. Embora, em última análise, essas teclas não façam 
com que códigos ASCII sejam retornados para o processo de usuário, elas geram códigos de 
varredura indicando qual tecla foi pressionada (o driver pode distinguir entre as teclas Shift 
da direita e da esquerda, se desejado) e ainda causam duas interrupções por tecla. 

A interrupção de teclado é IRQ 1. Essa linha de interrupção não é acessível no barra- 
mento do sistema e não pode ser compartilhada por nenhum outro adaptador de E/S. Quan- 
do _hwint0] (linha 6535) chamar intr handle (linha 8221), não haverá uma longa lista de 
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Interrupção» a e 
/ Interrupção arefa de 
* de teclado,” : 


Figura 3-33 Requisição de leitura do teclado quando nenhum caractere está pendente. FS é 
o sistema de arquivos (File System). TTY é o driver de terminal. O TTY recebe uma mensa- 
gem para cada tecla pressionada e enfileira códigos de varredura (scan codes) à medida que 
são inseridos. Posteriormente, eles são interpretados e montados em um buffer de códigos 
ASCII, o qual é copiado no processo de usuário. 


ganchos para percorrer, para verificar o TTY que deve ser notificado. Na Figura 3-33, mos- 
tramos a tarefa de sistema originando a mensagem de notificação (4), pois ela é gerada por 
generic handler em system/do irgctl.c (não listado), mas essa rotina é chamada diretamente 
pelas rotinas de processamento de interrupção de baixo nível. O processo da tarefa de siste- 
ma não é ativado. Ao receber uma mensagem HARD INT, tty task (linha 13740) despacha 
para kbd interrupt (linha 15335), a qual, por sua vez, chama scan keyboard (linha 15800). 
Scan keyboard faz três chamadas de núcleo (5, 6, 7) para que a tarefa de sistema leia e es- 
creva em várias portas de E/S, as quais, em última análise, retornam o código de varredura, e 
então seja adicionada em um buffer circular. Então, um flag tty events é ativado para indicar 
que esse buffer contém caracteres e não está vazio. 

Nesse ponto, nenhuma mensagem é necessária. Sempre que o laço principal de tty task 
inicia outro ciclo, ele inspeciona o flag tty events de cada dispositivo de terminal e, para cada 
dispositivo que tenha o flag ativado, chama handle events (linha 14358). O flag tty events 
pode sinalizar vários tipos de atividade (embora a entrada seja a mais provável); portanto, 
handle events sempre chama as funções específicas do dispositivo para entrada e para saída. 
Para entrada a partir do teclado, isso resulta em uma chamada para kb read (linha 15360), 
que monitora os códigos de teclado que indicam pressionamento ou liberação das teclas 
CTRL, SHIFT e ALT e converte códigos de varredura em códigos ASCII. Kb read, por sua 
vez, chama in process (linha 14486), que processa os códigos ASCII, levando em conta os 
caracteres especiais e os diferentes flags que podem estar ativos, incluindo o fato de o modo 
canônico estar ou não em vigor. Normalmente, o efeito é adicionar caracteres na fila de en- 
trada do console em tty table, embora alguns códigos, por exemplo, BACKSPACE, tenham 
outros efeitos. Normalmente, além disso, in process inicia o eco dos códigos ASCII na tela. 

Quando caracteres suficientes tiverem chegado, o driver de terminal faz outra chamada 
de núcleo (8) para pedir à tarefa de sistema para que copie os dados no endereço solicitado 
pelo shell. A cópia dos dados não é uma passagem de mensagem e, por isso, está mostrada 
com linhas tracejadas (9) na Figura 3-33. É mostrada mais de uma linha porque pode haver 
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mais de uma operação dessas antes que a requisição do usuário tenha sido completamente 
atendida. Quando a operação é completada, o driver de terminal envia uma mensagem para o 
sistema de arquivos, dizendo a ele que o trabalho foi feito (10), e o sistema de arquivos reage 
a essa mensagem enviando uma mensagem de volta para o shell, para desbloqueá-lo (11). 

A definição de quando chegaram caracteres suficientes depende do modo do terminal. 
No modo canônico, uma requisição está completa quando é recebido um código de avanço 
de linha, final de linha ou final de arquivo e, para a realização do processamento de entrada 
correto, uma linha de entrada não pode ultrapassar o tamanho da fila de entrada. No modo 
não-canônico, uma leitura pode solicitar um número muito maior de caracteres e in process 
pode ter de transferir caracteres mais de uma vez, antes que uma mensagem seja retornada 
para o sistema de arquivos para indicar que a operação está concluída. 

Note que a tarefa de sistema copia os caracteres reais diretamente do espaço de en- 
dereçamento do TTY para o do shell. Eles não passam pelo sistema de arquivos. No caso 
da E/S de bloco, os dados passam pelo sistema de arquivos para permitir que ele mantenha 
uma cache dos blocos usados mais recentemente. Se acontecer de um bloco solicitado estar 
na cache, a requisição poderá ser atendida diretamente pelo sistema de arquivos, sem fazer 
nenhuma E/S de disco real. 

Para E/S de teclado, a cache não faz sentido. Além disso, uma requisição do sistema de 
arquivos para um driver de disco sempre pode ser atendida em, no máximo, algumas centenas 
de milissegundos; portanto, não há nenhum problema em fazer o sistema de arquivos espe- 
rar. A E/S de teclado pode demorar várias horas para terminar, ou pode nunca terminar. No 
modo canônico, o driver de terminal espera por uma linha completa e também pode esperar 
por um longo tempo no modo não-canônico, dependendo das configurações de MIN e TIME. 
Assim, é inaceitável fazer o sistema de arquivos bloquear até que uma requisição de entrada 
do terminal seja atendida. 

Posteriormente, pode acontecer de o usuário ter digitado antecipadamente e os caracte- 
res estarem disponíveis antes de terem sido solicitados, a partir de interrupções anteriores e 
do evento 4. Nesse caso, os eventos 1,2 e de 5 a 11 acontecem todos em uma rápida sucessão, 
após o requisição de leitura; 3 nem mesmo ocorre. 

Os leitores familiarizados com as versões anteriores do MINIX podem se lembrar que 
nelas o driver TTY (e todos os outros drivers) era compilado junto com o núcleo. Cada driver 
tinha sua própria rotina de tratamento de interrupção em espaço de núcleo. No caso do driver 
de teclado, a própria rotina de tratamento de interrupção podia colocar no buffer certo núme- 
ro de códigos de varredura e também realizar algum processamento preliminar (os códigos 
de varredura da maioria das liberações de tecla podiam ser eliminados, somente para teclas 
modificadoras, como a tecla Shift, era necessário colocar os códigos de liberação no buffer). 
A rotina de tratamento de interrupção em si não enviava mensagens para o driver TTY, pois 
era alta a probabilidade de que o TTY não fosse bloqueado em uma operação receive e fosse 
capaz de receber uma mensagem a qualquer momento. Em vez disso, a rotina de tratamento 
de interrupção de relógio despertava o driver TTY periodicamente. Essas técnicas foram 
adotadas para evitar a perda da entrada do teclado. 

Anteriormente, demos importância para as diferenças entre tratar de interrupções es- 
peradas, como aquelas geradas por uma controladora de disco, e tratar de interrupções im- 
previsíveis, como as de um teclado. Mas, no MINIX 3, nada de especial parece ter sido feito 
para tratar dos problemas das interrupções imprevisíveis. Como isso é possível? Algo a ser 
lembrado é a enorme diferença no desempenho entre os computadores para os quais as pri- 
meiras versões do MINIX foram escritas e os projetos atuais. As velocidades de relógio da 
CPU aumentaram e o número de ciclos de relógio necessários para executar uma instrução 
diminuiu. O processador mínimo recomendado para usar com o MINIX 3 é um 80386. Um 
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80386 lento executará instruções aproximadamente 20 vezes mais rápido do que o IBM PC 
original. Um Pentium de 100 MHz executará, talvez, 25 vezes mais rápido do que o 80386 
lento. Portanto, talvez a velocidade da CPU seja suficiente. 

Outra coisa a ser lembrada é que a entrada do teclado é muito lenta para os padrões 
do computador. A 100 palavras por minuto, uma pessoa digita menos de 10 caracteres por 
segundo. Mesmo para uma pessoa rápida, o driver de terminal provavelmente enviará uma 
mensagem de interrupção para cada caractere digitado no teclado. Entretanto, no caso de ou- 
tros dispositivos de entrada, taxas de dados mais altas são prováveis — velocidades de 1000 
ou mais vezes mais rápidas do que as de uma pessoa são possíveis a partir de uma porta serial 
conectada a um modem de 56.000 bps. Nessa velocidade, aproximadamente 120 caracteres 
podem ser recebidos pelo modem entre os tiques de relógio, mas para permitir compactação 
de dados no enlace do modem, a porta serial conectada a ele deve ser capaz de manipular pelo 
menos duas vezes mais. 

Entretanto, algo a considerar no caso de uma porta serial é que são transmitidos carac- 
teres e não códigos de varredura; portanto, mesmo com uma UART antiga, que não utiliza 
buffer, haverá apenas uma interrupção por tecla pressionada, em vez de duas. E os PCs mais 
recentes são equipados com UART's que normalmente colocam no buffer pelo menos 16 e, 
talvez, até 128 caracteres. Assim, não é exigida uma interrupção por caractere. Por exemplo, 
uma UART com um buffer de 16 caracteres poderia ser configurada para interromper quando 
14 caracteres estivessem no buffer. As redes baseadas em Ethernet podem distribuir caracte- 
res a uma velocidade muito mais rápida do que uma linha serial, mas os adaptadores Ethernet 
colocam no buffer pacotes inteiros e apenas uma interrupção é necessária por pacote. 

Concluiremos nossa visão geral sobre a entrada de terminal resumindo os eventos que 
ocorrem quando o driver de terminal é ativado pela primeira vez por uma requisição de lei- 
tura e quando ele é reativado após receber a entrada do teclado (veja a Figura 3-34). No 
primeiro caso, quando chega uma mensagem no driver de terminal solicitando caracteres do 
teclado, a função principal, tty task (linha 13740) chama do read (linha 13953) para tratar da 
requisição. Do read armazena os parâmetros da chamada na entrada do teclado em tty table, 
no caso de haver caracteres insuficientes no buffer para atender a requisição. 

Então, ela chama in transfer (linha 14416) para obter qualquer entrada que já esteja 
esperando e, depois, chama handle events (linha 14358) que, por sua vez, chama (por inter- 
médio do ponteiro de função (*tp->tty devread)) kb read (linha 15360) e, então, in trans- 
fer mais uma vez, para tentar extrair mais alguns caracteres do fluxo de entrada. Kb read 
chama várias outras funções que não aparecem na Figura 3-34, para realizar seu trabalho. 
O resultado é que, o que estiver imediatamente disponível será copiado para o usuário. Se 
nada estiver disponível, nada será copiado. Se a leitura for completada por in transfer, ou 
por handle events, uma mensagem será enviada para o sistema de arquivos quando todos 
os caracteres tiverem sido transferidos, para que o sistema de arquivos possa desbloquear o 
processo que fez a chamada. Se a leitura não terminou (nenhum caractere ou caracteres insu- 
ficientes) do. read informará o sistema de arquivos, dizendo se deve suspender o processo que 
fez a chamada original ou, se foi solicitada uma leitura sem bloqueio, cancelar a leitura. 

O lado direito da Figura 3-34 resume os eventos que ocorrem quando o driver de termi- 
nal é despertado após uma interrupção do teclado. Quando um caractere é digitado, a “rotina 
de tratamento: de interrupção kbd interrupt (linha 15335) executa scan keyboard, que chama 
a tarefa de sistema para realizar a E/S. (Colocamos rotina de tratamento entre aspas porque 
não é chamada uma rotina de tratamento real quando ocorre uma interrupção, ela é ativada 
por uma mensagem enviada para tty task a partir de generic handler na tarefa de sistema.) 
Então, kbd interrupt coloca o código de varredura no buffer de teclado, ibuf, e ativa um flag 
para identificar que o dispositivo de console experimentou um evento. Quando kbd interrupt 
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Recebe mensagem do 
usuário via sistema 
de arquivos 


Outras funções 


Recebe mensagem 
do relógio 


handle events 


Outras funções 


Figura 3-34 Tratamento de entrada no driver de terminal. O ramo esquerdo da árvore é 
percorrido para processar uma requisição para ler caracteres. O ramo direito é percorrido 
quando uma mensagem de teclado é enviada para o driver antes que um usuário tenha soli- 
citado entrada. 


retorna o controle para tty task, um comando continue resulta no início de outra iteração 
do laço principal. Os flags de evento de todos os dispositivos de terminal são verificados e 
handle events é chamada para cada dispositivo com um flag posicionado. No caso do tecla- 
do, handle events chama kb read e in transfer, exatamente como foi feito na recepção da 
requisição de leitura original. Os eventos mostrados no lado direito da figura podem ocorrer 
várias vezes, até que sejam recebidos caracteres suficientes para atender a requisição aceita 
por do read, após a primeira mensagem do sistema de arquivos. Se o sistema de arquivos 
tentar iniciar uma requisição por mais caracteres a partir do mesmo dispositivo, antes que a 
primeira requisição tenha terminada, será retornado um erro. Naturalmente, cada dispositivo 
é independente: uma requisição de leitura em nome de um usuário em um terminal remoto é 
processado separadamente de outro feito por um usuário que esteja no console. 

As funções não mostradas na Figura 3-34 que são chamadas por kb read incluem 
map key (linha 15303), que converte os códigos de tecla (códigos de varredura) gerados pelo 
hardware em códigos ASCII, make break (linha 15431), que monitora o estado das teclas 
modificadoras, como a tecla SHIFT, e in process (linha 14486), que trata de complicações 
como tentativas por parte do usuário de retroceder em uma entrada inserida por engano, outros 
caracteres especiais e opções disponíveis em diferentes modos de entrada. In process também 
chama tty echo (linha 14647), para que os caracteres digitados sejam exibidos na tela. 


Saída de terminal 


Em geral, a saída de console é mais simples do que a entrada do terminal, pois o sistema 
operacional está no controle e não precisa se preocupar com requisições de saída chegando 
em momentos inconvenientes. Além disso, como o console do MINIX 3 é mapeado em me- 
mória, a saída para o console é particularmente simples. Nenhuma interrupção é necessária: a 
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operação básica é copiar dados de uma região da memória para outra. Por outro lado, todos os 
detalhes do gerenciamento do vídeo, incluindo o tratamento de sequências de escape, devem 
ser manipulados pelo software do driver. Assim como fizemos no caso da entrada de tecla- 
do, na seção anterior, acompanharemos as etapas envolvidas no envio de caracteres para o 
monitor usado como console de saída. Vamos supor, neste exemplo, que o monitor ativo está 
sendo escrito; as complicações secundárias, causadas pelos consoles virtuais, serão discutidas 
posteriormente. 

Quando um processo deseja imprimir algo, ele geralmente chama printf. Printf chama 
write para enviar uma mensagem para o sistema de arquivos. A mensagem contém um pontei- 
ro para os caracteres que devem ser impressos (não para os caracteres em si). Então, o sistema 
de arquivos envia uma mensagem para o driver de terminal, o qual os busca e copia na RAM 
de vídeo. A Figura 3-35 mostra as principais funções envolvidas na saída. 


Fim da linha 
Caracteres | 
“fáceis” 1 

A 


scroll_screen 


Figura 3-35 Principais funções usadas na saída do terminal. A linha tracejada indica carac- 
teres copiados diretamente para ramqueue por cons_write. 


Quando chega uma mensagem no driver de terminal solicitando escrita na tela, do_write 
(linha 14029) é chamada para armazenar os parâmetros na estrutura tty do console em tty table. 
Então, handle events (a mesma função chamada quando o flag tty events é encontrado ativo) 
é chamada. Essa função chama as rotinas de entrada e saída para o dispositivo selecionado em 
seu argumento. No caso do monitor do console, isso significa que qualquer entrada de tecla- 
do que esteja esperando é processada primeiro. Se há uma entrada esperando, os caracteres 
a serem ecoados são adicionados aos caracteres que já estão esperando saída. Então, é feita 
uma chamada para cons. write (linha 16036), a função de saída para monitores mapeados em 
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memória. Essa função usa phys copy para copiar blocos de caracteres do processo de usuário 
para um buffer local, possivelmente repetindo várias vezes esta etapa e as seguintes, pois o 
buffer local suporta apenas 64 bytes. Quando o buffer local está cheio, cada byte é transferido 
para outro buffer, ramqueue. Esse buffer é um array de palavras de 16 bits. Bytes alternados 
são preenchidos com o valor corrente do byte de atributo de tela, o qual determina as cores de 
primeiro e de segundo plano e outros atributos. Quando possível, os caracteres são transferidos 
diretamente para ramqueue, mas certos caracteres, como os de controle ou os caracteres que 
fazem parte de sequências de escape, precisam de tratamento especial. Um tratamento especial 
também é exigido quando a posição na tela de um caractere ultrapassa a largura da tela ou 
quando ramqueue fica cheio. Nesses casos, out char (linha 16119) é chamada para transferir os 
caracteres e executar qualquer outra ação adicional solicitada. Por exemplo, scroll screen (linha 
16205) é chamada quando um caractere de avanço de linha é recebido enquanto se está ende- 
reçando a última linha da tela e parse escape manipula caracteres durante uma segiiência de 
escape. Normalmente, out char chama flush (linha 16259), que copia o conteúdo de ramqueue 
na memória do monitor de vídeo, usando a rotina em linguagem assembly mem vid copy. Flush 
também é chamada depois que o último caractere é transferido para ramqueue, para garantir que 
toda a saída seja exibida. O resultado final de flush é fazer com que o chip da controladora de 
vídeo 6845 exiba o cursor na posição correta. 

Logicamente, os bytes oriundos do processo de usuário poderiam ser escrito na RAM 
de vídeo, um por iteração do laço. Entretanto, é mais eficiente acumular os caracteres em 
ramqueue e depois copiar o bloco com uma chamada para mem vid copy no modo de me- 
mória protegida dos processadores da classe Pentium. É interessante notar que essa técnica 
foi introduzida nas versões anteriores do MINIX 3, que eram executadas em processadores 
mais antigos, sem memória protegida. A precursora de mem vid copy tratava de um proble- 
ma de sincronização — nos monitores de vídeo mais antigos, a cópia na memória de vídeo 
tinha de ser feita quando a tela era limpa, durante o retraço vertical do feixe do CRT, para 
evitar a geração de sobras visuais em toda a tela. O MINIX 3 não fornece mais esse suporte, 
pois a penalidade no desempenho é grande demais e esses dispositivos já são obsoletos. En- 
tretanto, a versão moderna do MINIX 3 tira proveito de outras maneiras de copiar ramqueue 
como um bloco. 

A RAM de vídeo disponível para um console é delimitada na estrutura console pelos 
campos c starte c limit. A posição corrente do cursor é armazenada nos campos c column e 
c row. A coordenada (0, 0) é o canto superior esquerdo da tela, que é onde o hardware come- 
ça a preencher a tela. Cada varredura do vídeo começa no endereço dado por c org e continua 
por 80 x 25 caracteres (4000 bytes). Em outras palavras, o chip 6845 extrai a palavra no des- 
locamento c org da RAM de vídeo e exibe o byte do caractere no canto superior esquerdo, 
usando o byte de atributo para controlar a cor, o piscamento etc. Então, ele busca a próxima 
palavra e exibe o caractere em (1, 0). Esse processo continua até chegar a (79, 0), momento 
esse em que ele inicia a segunda linha na tela, na coordenada (0, 1). 

Quando o computador é iniciado pela primeira vez, a tela é limpa, a saída é escrita na 
RAM de vídeo a partir da posição c starte c org recebe o mesmo valor de c start. Assim, a 
primeira linha aparece na linha superior da tela. Quando a saída deve ir para uma nova linha, 
ou porque a primeira linha está cheia ou porque um caractere de nova linha foi detectado 
por out char, a saída é escrita no local dado por c start mais 80. Finalmente, todas as 25 
linhas são preenchidas e é exigida a rolagem da tela. Alguns programas, como os editores, 
por exemplo, também exigem rolagem para baixo quando o cursor está na linha superior e é 
necessário mover mais para cima no texto. 

Existem duas maneiras pela qual a rolagem da tela pode ser gerenciada. Na rolagem 
por software, o caractere a ser exibido na posição (0, 0) está sempre na primeira posição na 
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memória de vídeo, a palavra O em relação à posição apontada por c start, e o chip da contro- 
ladora de vídeo é instruído a exibir essa posição primeiro, mantendo o mesmo endereço em 
c org. Quando a tela precisa ser rolada, o conteúdo da posição relativa 80 na RAM de vídeo, 
o início da segunda linha na tela, é copiado na posição relativa 0, a palavra 81 é copiada na 
posição relativa 1 e assim por diante. A segiiência de varredura permanece inalterada, colo- 
cando os dados na posição O da memória na posição (0, 0) da tela e a imagem na tela parece 
ter se movido uma linha para cima. O custo é que a CPU moveu 80 x 24 =1920 palavras. 
Na rolagem por hardware, os dados não são movidos na memória; em vez disso, o chip da 
controladora de vídeo é instruído a começar a exibição em um ponto diferente, por exemplo, 
com os dados na palavra 80. A contabilidade é feita somando-se 80 ao conteúdo de c org, 
salvando-o para referência futura e gravando esse valor no registrador correto do chip da 
controladora de vídeo. Isso exige que a controladora seja inteligente o suficiente para circular 
pela RAM de vídeo, extraindo dados do início da memória RAM (o endereço presente em 
c start) quando ela chega ao fim (o endereço contido em c limit), ou que a RAM de vídeo 
tenha mais capacidade do que apenas as 80 x 2000 palavras necessárias para armazenar uma 
única tela de exibição. 

Os adaptadores de vídeo mais antigos geralmente têm memória menor, mas são capazes 
de circular e fazer rolagem por hardware. Os adaptadores mais recentes geralmente têm muito 
mais memória do que o necessário para exibir uma única tela de texto, mas não são capazes de 
circular. Assim, um adaptador com 32.768 bytes de memória de vídeo pode conter 204 linhas 
completas de 160 bytes cada uma e pode fazer rolagem por hardware 179 vezes, antes que a in- 
capacidade de circular se torne um problema. Mas, finalmente, uma operação de cópia de me- 
mória será necessária para mover os dados das últimas 24 linhas de volta para a posição O na 
memória de vídeo. Qualquer que seja o método utilizado, uma fileira de espaços em branco é 
copiada na RAM de vídeo para garantir que a nova linha na parte inferior da tela esteja vazia. 

Quando os consoles virtuais estão ativados, a memória disponível dentro de um adap- 
tador de vídeo é dividida igualmente entre o número de consoles desejados, inicializando-se 
adequadamente os campos c start e c limit de cada console. Isso afeta a rolagem. Em qual- 
quer adaptador grande o bastante para suportar consoles virtuais, de vez em quando ocorre a 
rolagem por software, mesmo que a rolagem por hardware esteja em vigor. Quanto menor a 
quantidade de memória disponível para cada monitor de console, mais frequentemente a rola- 
gem por software deve ser usada. O limite é atingido quando é configurado o número máximo 
possível de consoles. Então, toda operação de rolagem será por software. 

A posição do cursor relativa ao início da RAM de vídeo pode ser deduzida de c column 
ec row, mas é mais rápido armazená-la explicitamente (in c cur). Quando um caractere 
precisa ser impresso, ele é colocado na RAM de vídeo, na posição c cur, a qual é então atu- 
alizada, assim como acontece com c column. A Figura 3-36 resume os campos da estrutura 
console que afetam a posição corrente e a origem da exibição. 


Campo Significado 
c start Início da memória de vídeo para esse console 
c limit Limite da memória de vídeo para esse console 


c column | Coluna corrente (0-79) com 0 na esquerda 


Cc row Linha corrente (0-24) com 0 na parte superior 
c cur Deslocamento na RAM de vídeo para o cursor 
c org Posição na memória RAM apontada pelo registrador de base do chip 6845 


Figura 3-36 Campos da estrutura console relacionados à posição corrente na tela. 
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Os caracteres que afetam a posição do cursor (por exemplo, avanço de linha, retrocesso) 
são manipulados ajustando-se os valores de c column, c row e c cur. Esse trabalho é feito 
no final de flush, por uma chamada para set 6845, que configura os registradores no chip da 
controladora de vídeo. 

O driver de terminal suporta sequências de escape para permitir que editores de tela e 
outros programas interativos atualizem a tela de uma maneira flexível. As sequências suporta- 
das são um subconjunto de um padrão ANSI e devem ser adequadas para permitir que muitos 
programas escritos para outro hardware e outros sistemas operacionais sejam facilmente por- 
tados para o MINIX 3. Existem duas categorias de segiiências de escape: as que nunca con- 
têm um parâmetro variável e as que podem conter parâmetros. Na primeira categoria, a única 
representante suportada pelo MINIX 3 é ESCM, que indexa a tela inversamente, movendo o 
cursor uma linha para cima e rolando a tela para baixo, caso o cursor já esteja na primeira li- 
nha. A outra categoria pode ter um ou dois parâmetros numéricos. Todas as segiiências desse 
grupo começam com ESC [. O caractere “[” é o introdutor de segiiência de controle. Uma 
tabela de segiiências de escape definidas pelo padrão ANSI e reconhecidas pelo MINIX 3 foi 
mostrada na Figura 3-32. 

Analisar sequências de escape não é simples. As sequências de escape válidas no MI- 
NIX 3 podem ter apenas dois caracteres, como em ESC M, ou até 8 caracteres de compri- 
mento, no caso de uma segiiência que aceita dois parâmetros numéricos, cada um podendo ter 
valores de dois dígitos, como em ESC [20;60H, que move o cursor para a linha 20, coluna 60. 
Em uma seqiiência que aceita um único parâmetro, este pode ser omitido; em uma seqiiência 
que aceita dois parâmetros, um deles ou ambos podem ser omitidos. Quando um parâmetro é 
omitido, ou é utilizado um parâmetro que está fora do intervalo válido, ele é substituído por 
um padrão. O padrão é o menor valor válido. 

Considere as seguintes maneiras pelas quais um programa poderia construir uma se- 
qiiência para mover o cursor para o canto superior esquerdo da tela: 


1. ESC [H é aceitável, pois se nenhum parâmetro for inserido, os parâmetros válidos 
mais baixos serão assumidos. 


2. ESC [1;1H enviará o cursor corretamente para a linha 1 e coluna 1 (no padrão 
ANSI, os números de linha e coluna começam em 1). 


3. Tanto ESC [1;H como ESC [;1H têm um parâmetro omitido, o que leva ao padrão 
1, como no primeiro exemplo. 


4. ESC [0;0H fará o mesmo, pois cada parâmetro é menor do que o valor mínimo 
válido e este será usado. 


Esses exemplos foram apresentados não para sugerir que se deva usar deliberadamen- 
te parâmetros inválidos, mas para mostrar que o código que analisa tais segiiências não é 
simples. 

O MINIX 3 implementa uma máquina de estado finito para fazer essa análise. A variá- 
velc esc state na estrutura console normalmente tem o valor 0. Quando out char detecta um 
caractere ESC, ela muda c esc state para 1 e os caracteres subsegiientes são processados por 
parse escape (linha 16293). Se o caractere seguinte for o introdutor de segiiência de contro- 
le, entra-se no estado 2; caso contrário, a segiiência será considerada concluída e do escape 
(linha 16352) será chamada. No estado 2, contanto que os caracteres recebidos sejam numé- 
ricos, um parâmetro é calculado multiplicando-se o valor anterior do parâmetro (inicialmente 
0) por 10 e somando-se o valor numérico do caractere corrente. Os valores de parâmetro são 
mantidos em um array e, quando um ponto-e-vírgula é detectado, o processamento muda 
para a próxima célula no array. (No MINIX 3, o array tem apenas dois elementos, mas o 
princípio é o mesmo.) Quando é encontrado um caractere não-numérico que não é um ponto- 
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e-vírgula, a segiiência é considerada concluída e, novamente, do escape é chamada. O ca- 
ractere corrente na entrada para do escape é usado então, para selecionar exatamente a ação 
a ser executada e como os parâmetros serão interpretados, sejam os padrões, sejam aqueles 
inseridos no fluxo de caracteres. Isso está ilustrado na Figura 3-44. 


Mapas de teclado carregáveis 


O teclado do IBM PC não gera códigos ASCII diretamente. Cada uma das teclas é identifi- 
cada por um número, começando com as teclas localizadas no canto superior esquerdo do 
teclado original do PC — 1 para a tecla “ESC”, 2 para a tecla “1” e assim por diante. Cada 
tecla recebe um número, incluindo as teclas modificadoras, como SHIFT (da direita e da 
esquerda), numeradas como 42 e 54. Quando uma tecla é pressionada, o MINIX 3 recebe 
o número da tecla como código de varredura. Um código de varredura também é gerado 
quando uma tecla é liberada, mas o código gerado na liberação tem o bit mais significativo 
ativado (equivalente a somar 128 ao número da tecla). Assim, um pressionamento e uma libe- 
ração de uma tecla podem ser distinguidos. Monitorando-se quais teclas modificadoras foram 
pressionadas e ainda não liberadas, é possível um grande número de combinações. É claro 
que, para propósitos normais, combinações de duas teclas, como SHIFT-A ou CTRL-D, são 
mais fáceis de manejar para pessoas que digitam com as duas mãos, mas para ocasiões espe- 
ciais, combinações de três teclas (ou mais) são possíveis; por exemplo, CTRL-SHIFT-A ou a 
conhecida combinação CTRL-ALT-DEL, que os usuários de PC conhecem como a maneira 
para reinicializar o sistema. 

A complexidade do teclado do PC permite uma grande flexibilidade no modo como 
ele é usado. Um teclado padrão tem 47 teclas de caractere normais definidas (26 alfabéticas, 
10 numéricas e 11 de pontuação). Se quisermos usar combinações de três teclas modificado- 
ras, como CTRL-ALT-SHIFT, podemos suportar um conjunto de caracteres de 376 (8 x 47) 
membros. De modo algum esse é o limite do que é possível, mas vamos supor, por enquanto, 
que não queremos distinguir entre as teclas modificadoras da esquerda e da direita, nem usar 
nenhuma das teclas do teclado numérico ou de função. Na verdade, não estamos limitados 
a usar apenas as teclas CTRL, ALT e SHIFT como modificadoras; poderíamos remover al- 
gumas teclas do conjunto de teclas normais e usá-las como modificadoras, se quiséssemos 
escrever um driver que suportasse tal sistema. 

Os sistemas operacionais usam um mapa de teclado para determinar o código de ca- 
ractere a ser passado para um programa, com base na tecla que está sendo pressionada e as 
modificadoras que estão em vigor. Logicamente, o mapa de teclado do MINIX 3 é um array 
de 128 linhas, representando os valores de código de varredura possíveis (esse tamanho foi 
escolhido para atender os teclados japoneses; os teclados norte-americanos e europeus não 
têm tantas teclas), e 6 colunas. As colunas representam nenhuma modificadora, a tecla SHIFT, 
a tecla CTRL, a tecla ALT da esquerda, a tecla ALT da direita e uma combinação de uma das 
teclas ALT com a tecla SHIFT. Assim, há 720 ((128 - 6) x 6) códigos de caractere que podem 
ser gerados por esse esquema, dado um teclado adequado. Isso exige que cada entrada da 
tabela seja uma quantidade de 16 bits. Para os teclados norte-americanos, as colunas ALT e 
ALT? são idênticas. ALT2 é chamada ALTGR nos teclados de outros idiomas e muitos desses 
mapas de teclado suportam teclas com três símbolos, usando essa tecla como modificadora. 

Um mapa de teclado padrão, determinado pela linha 


tinclude keymaps/us-std.src 
em keyboard.c, é compilado no núcleo do MINIX 3, mas uma chamada a 


ioctI(0, KIOCSMAP, keymap) 
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pode ser usada para carregar um mapa diferente no núcleo, no endereço keymap. Um mapa 
de teclado completo ocupa 1536 bytes (128 x 6 x 2). Os mapas de teclado extras são arma- 
zenados em forma compactada. Um programa chamado genmap é usado para fazer um novo 
mapa de teclado compactado. Quando compilado, genmap inclui o código de keymap.src 
para um mapa de teclado em particular, para que o mapa seja compilado dentro de genmap. 
Normalmente, genmap é executado imediatamente após ser compilado, no momento em que 
produz na saída a versão compactada de um arquivo e, então, o binário de genmap é excluí- 
do. O comando loadkeys lê um mapa de teclado compactado, o expande internamente e, em 
seguida, chama ioctl para transferir o mapa de teclado para a memória do núcleo. O MINIX 
3 pode executar loadkeys automaticamente na inicialização e o programa também pode ser 
ativado a qualquer momento pelo usuário. 


Código de 

varredura | Caractere | Normal | SHIFT | ALT1 ALT2 | ALT+SHIFT | CTRL 
00 nenhum 0 0 0 0 0 0 
01 ESC cP) | CC) | CAC) | CAC) CA(T) c(T) 
02 e T P A(‘1’) A(T’) A(!) C('A? 
13 = = + A('=" A('=" A(+) C('o”) 
16 q | Maq) | OQ |a) | MG) | AQ) | CO) 
28 CR/LF C(M) | C(M) | CA(M’) | CA(M’) CA(‘M’) C('J”) 
29 CTRL CTRL | CTRL | CTRL | CTRL CTRL CTRL 
59 F1 F1 SF1 AF1 AF1 ASF1 CF1 
127 299 0 0 0 0 0 0 


Figura 3-37 Algumas entradas do arquivo-fonte de um mapa de teclado. 


O código-fonte de um mapa de teclado define um grande array inicializado e, para eco- 
nomizar espaço, o arquivo de mapa de teclado não foi impresso no Apêndice B. A Figura 3-37 
mostra, em forma de tabela, o conteúdo de algumas linhas de src/kernel/keymaps/us-std.src, 
que ilustra vários aspectos dos mapas de teclado. Não há nenhuma tecla no teclado do IBM- 
PC que gere o código de varredura 0. A entrada do código 1, a tecla ESC, mostra que o valor 
retornado não é alterado quando a tecla SHIFT ou a tecla CTRL é pressionada, mas que um 
código diferente é retornado quando uma tecla ALT é pressionada simultaneamente com a 
tecla ESC. Os valores compilados nas várias colunas são determinados por macros definidas 
em include/minix/keymaps.h: 


tdefine C(c) ((c) &0x1F) /* Mapeamento para o código de controle */ 
tdefine A(c) ((c) | 0x80) /* Ativa oito bits (ALT) */ 

tdefine CA(c) A(C(c)) /* CTRL-ALT */ 

tdefine L(c) ((c)| HASCAPS) /* Adiciona o atributo “Caps Lock ativado” */ 


As três primeiras dessas macros manipulam bits no código do caractere entre apóstro- 
fos para produzir o código necessário a ser retornado para o aplicativo. A última ativa o bit 
HASCAPS no byte superior do valor de 16 bits. Trata-se de um flag indicando que o estado 
da variável capslock precisa ser verificado e o código possivelmente modificado, antes de 
ser retornado. Na figura, as entradas dos códigos de varredura 2, 13 e 16 mostram como as 
teclas numéricas, de pontuação e alfabéticas típicas são manipuladas. Para o código 28, vê- 
se um recurso especial — normalmente, a tecla ENTER produz o código CR — de carriage 
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return — (0x0D), representado aqui como C('M”. Como, nos arquivos do UNIX, o caractere 
de nova linha é o código LF — line feed — (0x0A) e, às vezes, é necessário inserir isso dire- 
tamente, esse mapa de teclado fornece uma combinação CTRL-ENTER, a qual produz esse 
código, C('J'). 

O código de varredura 29 é um dos códigos modificadores e deve ser reconhecido, in- 
dependentemente da outra tecla pressionada; portanto, o valor CTRL é retornado, indiferen- 
temente de qualquer outra tecla que possa ser pressionada. As teclas de função não retornam 
valores ASCII normais e a linha do código de varredura 59 mostra, simbolicamente, os valo- 
res (definidos em include/minix/keymaps.h) retornados para a tecla F1 combinada com outras 
modificadoras. Esses valores são F1: 0x0110, SF1: 0x1010, AF1: 0x0810, ASF1: 0x0C10 e 
CF1: 0x0210. A última entrada mostrada na figura, para o código de varredura 127, é típica de 
muitas entradas próximas ao final do array. Para muitos teclados, certamente para a maioria 
dos utilizados na Europa e nas Américas, não há teclas suficientes para gerar todos os códigos 
possíveis e essas entradas da tabela são preenchidas com zero. 


Fontes carregáveis 


Os primeiros PCs tinham os padrões para gerar caracteres em uma tela de vídeo armazenados 
apenas na memória ROM, mas os monitores usados nos dispositivos atuais fornecem memó- 
ria RAM nos adaptadores de vídeo, na qual podem ser carregados padrões personalizados 
para o gerador de caracteres. Isso é suportado pelo MINIX 3 com uma operação ioctl 


ioctI(O, TIOCSFON, font) 


O MINIX 3 suporta um modo de vídeo de 80 linhas x 25 colunas e os arquivos de fonte 
contêm 4096 bytes. Cada byte representa uma linha de 8 pixels que são iluminados se o valor 
do bit for 1, e 16 dessas linhas são necessárias para fazer o mapeamento de cada caractere. 
Entretanto, o adaptador de vídeo usa 32 bytes para fazer o mapeamento de cada caractere 
para fornecer uma resolução mais alta em modos atualmente não suportados pelo MINIX 
3. O comando loadfont é fornecido para converter esses arquivos na estrutura font de 8192 
bytes referenciada pela chamada de ioctl e usá-la para carregar a fonte. Assim como acontece 
com os mapas de teclado, uma fonte pode ser carregada no momento da inicialização ou a 
qualquer momento, durante a operação normal. Entretanto, todo adaptador de vídeo tem uma 
fonte padrão incorporada em sua memória ROM, que está disponível. Não há necessidade de 
compilar uma fonte no próprio MINIX 3 e o único suporte de fonte necessário no núcleo é o 
código para executar a operação ioctl TIOCSFON. 


Implementação do driver de terminal independente de dispositivo 


Nesta seção, começaremos a ver o código-fonte do driver de terminal em detalhes. Quando 
estudamos os dispositivos de bloco, vimos que vários drivers, suportando diversos dispositi- 
vos diferentes, podiam compartilhar uma base de software comum. O caso dos dispositivos 
de terminal é semelhante, mas com a diferença de que existe apenas um driver de terminal 
que suporta vários tipos de dispositivo de terminal. Aqui, começaremos com o código inde- 
pendente de dispositivo. Nas seções posteriores, veremos o código dependente de dispositivo 
para o teclado e para monitor de console mapeado em memória. 


Estruturas de dados do driver de terminal 


O arquivo tty.h contém definições usadas pelos arquivos em C que implementam os drivers 
de terminal. Como esse driver suporta muitos dispositivos diferentes, os números secundários 
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de dispositivo devem ser usados para distinguir qual dispositivo está sendo suportado em uma 
chamada específica e eles são definidos nas linhas 13405 a 13409. 

Dentro de tty.h, as definições dos flags O NOCTTY e O NONBLOCK (que são ar- 
gumentos opcionais para a chamada open) são duplicatas das definições presentes em 
include/fcntl.h, mas são repetidas aqui para não exigir a inclusão de outro arquivo. Os 
tipos devfun te devfunarg t (linhas 13423 e 13424) são usados para definir ponteiros para 
funções, a fim de fornecer chamadas indiretas usando um mecanismo semelhante àquele 
que vimos no código do laço principal dos drivers de disco. 

Muitas variáveis declaradas neste arquivo são identificadas pelo prefixo tty . A defini- 
ção mais importante em tty.h é a estrutura tty (linhas 13426 a 13488). Há uma estrutura dessas 
para cada dispositivo de terminal (juntos, o monitor do console e o teclado contam como um 
único terminal). A primeira variável na estrutura tty, tty events, é o flag ativado quando uma 
interrupção causa uma alteração que exige que o driver de terminal atenda o dispositivo. 

O restante da estrutura tty é organizado de forma a agrupar as variáveis que tratam 
da entrada, saída, status e informações sobre operações incompletas. Na seção de entrada, 
tty inhead e tty intail definem a fila onde os caracteres recebidos são colocados no buffer. 
Tty incount conta o número de caracteres presentes nessa fila e tty eotct conta linhas ou 
caracteres, conforme explicado a seguir. Todas as chamadas específicas do dispositivo são 
feitas indiretamente, com exceção das rotinas que inicializam os terminais, que são usadas 
para configurar os ponteiros empregados nas chamadas indiretas. Os campos tty devread e 
tty icancel contêm ponteiros para código específico do dispositivo, para executar as opera- 
ções de leitura e cancelamento de entrada. Tty min é usada em comparações com tty eotct. 
Quando esta última se torna igual à primeira, uma operação de leitura está concluída. Durante 
a entrada canônica, tty min é configurada como 1 e tty eotct conta as linhas inseridas. Du- 
rante a entrada não-canônica, tty eotct conta caracteres e tty min é configurada a partir do 
campo MIN da estrutura termios. Assim, a comparação das duas variáveis informa quando 
uma linha está pronta ou quando a contagem de caracteres mínima é atingida, dependendo do 
modo. Tty tmr é um temporizador para esse tty, usado para o campo TIME de termios. 

Como o enfileiramento da saída é manipulado pelo código específico do dispositivo, a 
parte da saída de tty não declara variáveis e é composta inteiramente em ponteiros para fun- 
ções específicas do dispositivo que escrevem, ecoam, enviam um sinal de quebra e cancelam 
a saída. Na parte de status, os flags tty reprint, tty escaped e tty inhibited indicam que o 
último caractere visto tem significado especial; por exemplo, quando um caractere CTRL-V 
(LNEXT) é detectado, tty escaped é configurado como 1 para indicar que qualquer significa- 
do especial do próximo caractere deve ser ignorado. 

A parte seguinte da estrutura contém dados sobre operações DEV READ, DEV WRITE 
e DEV JOCTL em andamento. Existem dois processos envolvidos em cada uma dessas ope- 
rações. O servidor que gerencia a chamada de sistema (normalmente, o sistema de arquivos) 
é identificado em tty incaller (linha 13458). O servidor chama o driver tty em nome de outro 
processo que precisa executar uma operação de E/S e esse cliente é identificado em tty inproc 
(linha 13459). Conforme descrito na Figura 3-33, durante uma operação read, os caracteres 
são transferidos diretamente do driver de terminal para um buffer dentro do espaço de memó- 
ria do processo original que fez a chamada. Tty inproce tty in vir localizam esse buffer. As 
duas variáveis seguintes, tty inleft e tty incum, contam os caracteres que ainda são necessá- 
rios e aqueles que já foram transferidos. Conjuntos de variáveis semelhantes são necessários 
para a chamada de sistema write. Para ioctl, pode haver uma transferência imediata de dados 
entre o processo solicitante e o driver; portanto, é necessário um endereço virtual, mas não há 
necessidade de variáveis para marcar o progresso de uma operação. Uma requisição de ioctl 
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pode ser adiada, por exemplo, até que a saída corrente tenha terminado, mas quando for o 
momento certo, a requisição será executada em uma única operação. 

Finalmente, a estrutura tty inclui algumas variáveis que não caem em nenhuma outra 
categoria, incluindo ponteiros para as funções para manipular as operações DEV IOCTL e 
DEV CLOSE no nível de dispositivo, uma estrutura termios estilo POSIX e uma estrutura 
winsize, que fornece suporte para monitores de tela baseados em janelas. A última parte da 
estrutura fornece armazenamento para a fila de entrada em si, no array tty inbuf. Note que 
esse é um array de uló t e não de caracteres char de 8 bits. Embora aplicativos e dispositi- 
vos utilizem códigos de 8 bits para caracteres, a linguagem C exige que a função de entrada 
getchar trabalhe com um tipo de dados maior para que possa retornar um valor de EOF sim- 
bólico, além de todos os 256 valores de byte possíveis. 

A tabela tty table, um array de estruturas tty, é declarada como extern na linha 13491. 
Há um elemento de array para cada terminal ativado pelas definições de NR CONS, NR RS . 
LINES e NR PTYS em include/minix/config.h. Para a configuração discutida neste livro, são 
ativados dois consoles, mas o MINIX 3 pode ser recompilado para adicionar mais consoles 
virtuais, uma ou duas linhas seriais e até 64 pseudoterminais. 

Existe uma outra definição extern em tty.h. Tty timers (linha 13516) é um ponteiro 
usado pelo temporizador para conter o início de uma lista encadeada de campos timer t. O 
arquivo de cabeçalho tty.h é incluído em muitos arquivos e o espaço de armazenamento para 
tty table e tty timers é alocado durante a compilação de tty.c. 

Duas macros, buflen e bufend, são definidas nas linhas 13520 e 13521. Elas são usadas 
fregientemente no código do driver de terminal, que faz muitas cópias de dados manipulando 
buffers. 


O driver de terminal independente de dispositivo 


O driver de terminal principal e as funções de suporte independentes de dispositivo estão 
todos em fty.c. Depois disso, aparecem várias definições de macro. Se um dispositivo não 
for inicializado, os ponteiros para as funções específicas desse dispositivo conterão zeros, 
postos lá pelo compilador C. Isso torna possível definir a macro tty active (linha 13687), a 
qual retorna FALSE se for encontrado um ponteiro nulo. É claro que o código de inicialização 
de um dispositivo não pode ser acessado indiretamente, se parte de sua tarefa é inicializar os 
ponteiros que tornam o acesso indireto possível. Nas linhas 13690 a 13696 estão definições 
de macros condicionais para igualar as chamadas de inicialização para dispositivos RS-232, 
ou de pseudoterminais, a chamadas de uma função nula, quando esses dispositivos não estão 
configurados. De maneira semelhante, do pty pode ser desativada nessa seção. Isso torna 
possível omitir inteiramente o código desses dispositivos, caso ele não seja necessário. 

Como existem tantos parâmetros que podem ser configurados para cada terminal e pode 
haver muitos terminais em um sistema interligado em rede, uma estrutura termios defaults é 
declarada e inicializada com valores padrão (todos os quais são definidos em include/termios.h), 
nas linhas 13720 a 13727. Essa estrutura é copiada na entrada tty table de um terminal, quando é 
necessário inicializá-lo ou reinicializá-lo. Os padrões para os caracteres especiais foram mostra- 
dos na Figura 3-29. A Figura 3-38 mostra os valores padrão para os vários flags usados. Na linha 
seguinte, a estrutura winsize defaults é declarada de modo semelhante. Ela é deixada para ser 
inicializada com zeros pelo compilador C. Essa é a ação padrão correta; ela significa “o tamanho 
da janela é desconhecido, use /etc/termcap”. 

O último conjunto de definições, antes que o código executável comece, são as decla- 
rações PUBLIC das variáveis globais anteriormente declaradas como extern em tty.h (linhas 
13731 a 13735). 
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Campo | Valores padrão 

c iflag BRKINT ICRNL IXON IXANY 

c oflag | OPOST ONLCR 

c cflag | CREAD CS8 HUPCL 

c lflag ISIG IEXTEN ICANON ECHO ECHOE 


Figura 3-38 Valores padrão de flags de termios. 


O ponto de entrada para o driver de terminal é tty task (linha 13740). Antes de entrar 
no laço principal, é feita uma chamada para tty init (linha 13752). As informações sobre a 
máquina hospedeira, que serão necessárias para inicializar o teclado e o console, são obtidas 
pela chamada de núcleo sys getmachine e, em seguida, o hardware de teclado é inicializado. 
A rotina chamada por isso é kb init once. Ela recebe esse nome para distingui-la de outra 
rotina de inicialização que é chamada como parte da inicialização de cada console virtual, 
posteriormente. Finalmente, um único O é impresso para exercitar o sistema de saída e dar 
a partida em tudo que não é inicializado até o primeiro uso. O código-fonte mostra uma 
chamada para printf, mas essa não é a mesma função printf utilizada pelos programas de 
usuário; trata-se de uma versão especial que chama uma função local no driver de console 
denominada putk. 

Em princípio, o laço principal, nas linhas 13764 a 13876, é igual ao laço principal de 
qualquer driver — ele recebe uma mensagem, executa um comando switch com o tipo de 
mensagem para chamar a função apropriada e, em seguida, gera uma mensagem de retorno. 
Entretanto, existem algumas complicações. A primeira é que, desde a última interrupção, 
mais caracteres podem ter sido lidos ou os caracteres a serem enviados a um dispositivo de 
saída podem estar prontos. Antes de tentar receber uma mensagem, o laço principal sempre 
verifica os flags tp->tty events de todos os terminais e handle events é chamada, conforme 
for necessário, para fazer o que não foi concluído. Somente quando nada exigir atenção ime- 
diata é que é feita uma chamada para receber. 

Nos comentários no início de tty.c (linha 13630) apresentam os tipos de mensagens 
usados mais frequentemente. Vários tipos de mensagem solicitando serviços especializados 
do driver de terminal não são mostrados. Eles não são específicos de nenhum dispositivo. O 
laço principal de tty task os verifica e trata deles antes de tratar as mensagens específicas do 
dispositivo. Primeiramente, é feita uma verificação de uma mensagem SYN ALARM e, se 
esse for o tipo de mensagem, é feita uma chamada para expire timers para causar a execução 
de uma rotina de cão de guarda. Em seguida, aparece um comando continue. Na verdade, 
todos os próximos casos que veremos são seguidos de continue. Falaremos mais sobre isso 
em breve. 

O próximo tipo de mensagem testado é HARD INT. Provavelmente, esse é o resultado 
de uma tecla sendo pressionada ou liberada no teclado local. Isso também poderia significar 
bytes recebidos por uma porta serial, caso as portas seriais estejam ativadas — na configura- 
ção que estamos estudando, elas não estão, mas deixamos o código condicional no arquivo 
para ilustrar como a entrada de porta serial seria tratada. Um campo de bit na mensagem é 
usado para determinar a fonte da interrupção. 

Em seguida, é feita uma verificação para SYS SIG. Os processos de sistema (drivers e 
servidores) devem ser bloqueados na espera por mensagens. Os sinais normais são recebi- 
dos apenas pelos processos ativos; portanto, o método de sinalização padrão do UNIX não 
funciona com processos de sistema. Uma mensagem SYS SIG é usada para sinalizar um pro- 
cesso de sistema. Um sinal para o driver de terminal pode significar que o núcleo está sendo 
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desligado (SIGKSTOP), que o driver de terminal está sendo desligado (SIGTERM) ou que o 
núcleo precisa imprimir uma mensagem no console (SIGKMESS), e as rotinas apropriadas 
são chamadas para esses casos. 

O último grupo de mensagens não específicas do dispositivo são PANIC DUMPBS, 
DIAGNOSTICS e FKEY CONTROL. Falaremos mais sobre elas quando chegarmos nas fun- 
ções que as atendem. 

Agora, passemos aos comandos continue: na linguagem C, continue, em um laço, faz 
com que o fluxo da execução retorne para o início dele. Portanto, se qualquer um dos tipos de 
mensagem mencionados até aqui for detectado, assim que for atendido retornará o controle 
para o início do laço principal, na linha 13764, a verificação de eventos será repetida e recei- 
ve será chamada novamente para esperar uma nova mensagem. Particularmente, no caso da 
entrada, é importante estar pronto para responder novamente o mais rápido possível. Além 
disso, se qualquer um dos testes de tipo de mensagem na primeira parte do laço for bem-su- 
cedido, não haverá necessidade de fazer nenhum dos testes que aparecem depois do primeiro 
comando switch. 

Anteriormente, mencionamos complicações com que o driver de terminal deve tratar. A 
segunda complicação é que esse driver atende vários dispositivos. Se a interrupção não for de 
hardware, o campo TTY LINE da mensagem é usado para determinar qual dispositivo deve 
responder à mensagem. O número secundário do dispositivo é decodificado por uma série 
de comparações, por meio das quais tp é apontado para a entrada correta na tabela tty table 
(linhas 13834 a 13847). Se o dispositivo é um pseudoterminal, do pty (em pty.c) é chamada e 
o laço principal é reiniciado. Neste caso, do pty gera a mensagem de resposta. Naturalmente, 
se os pseudoterminais não estiverem ativados, a chamada para do pty usará a macro fictícia 
definida anteriormente. Pode-se esperar que tentativas de acesso a dispositivos inexistentes 
não ocorram, mas é sempre mais fácil acrescentar outra verificação do que testar se não existe 
erros em outra parte do sistema. No caso de o dispositivo não existir, ou não estar configura- 
do, será gerada uma mensagem de resposta com uma mensagem de erro ENXIO e, novamen- 
te, o controle retornará para o início do laço. 

O restante desse driver é semelhante ao que vimos no laço principal de outros drivers, 
um comando switch para o tipo de mensagem (linhas 13862 a 13875). É chamada uma função 
apropriada para o tipo de requisição, do read, do write etc. Em cada caso, a função chamada 
gera a mensagem de resposta, em vez de passar as informações necessárias para construir a 
mensagem de volta para o laço principal. Uma mensagem de resposta é gerada no final do 
laço principal apenas se não foi recebido um tipo de mensagem válido, no caso em que é en- 
viada uma mensagem de erro EINVAL. Como as mensagens de resposta são enviadas a partir 
de muitos lugares diferentes dentro do driver de terminal, uma rotina comum, tty reply, é 
chamada para tratar dos detalhes da construção das mensagens de resposta. 

Se a mensagem recebida por tty task for um tipo de mensagem válido e não o resultado 
de uma interrupção (e não vier de um pseudoterminal), o switch no final do laço principal 
despachará para uma das funções do read, do write, do ioctl, do open, do close, do select 
ou do cancel. Os argumentos de cada uma dessas chamadas são tp, um ponteiro para uma 
estrutura tty e o endereço da mensagem. Antes de examinar cada uma delas em detalhes, 
mencionaremos algumas considerações gerais. Como tty task pode atender vários disposi- 
tivos de terminal, essas funções devem retornar rapidamente para que o laço principal possa 
continuar. 

Entretanto, do read, do write e do ioctl podem não conseguir completar imediatamen- 
te todo o trabalho solicitado. Para permitir que o sistema de arquivos atenda outras chamadas, 
é exigida uma resposta imediata. Se a requisição não puder ser concluída imediatamente, o 
código SUSPEND será retornado no campo de status da mensagem de resposta. Isso corres- 


318 


SISTEMAS OPERACIONAIS 


ponde à mensagem marcada como (3) na Figura 3-33 e suspende o processo que iniciou a 
chamada, enquanto desbloqueia o sistema de arquivos. As mensagens correspondentes a (10) 
e (11) na figura serão enviadas posteriormente, quando a operação puder ser concluída. Se 
a requisição puder ser completamente atendida, ou se ocorrer um erro, a contagem de bytes 
transferidos ou o código de erro será retornado no campo de status da mensagem de retorno 
para o sistema de arquivos. Neste caso, uma mensagem será enviada imediatamente do siste- 
ma de arquivos para o processo que fez a chamada original, para despertá-lo. 

Ler de um terminal é fundamentalmente diferente de ler de um dispositivo de disco. 
O driver de disco executa um comando no hardware de disco e, finalmente, os dados serão 
retornados, exceto no caso de uma falha mecânica ou elétrica. O computador pode exibir um 
prompt na tela, mas não há como obrigar uma pessoa que esteja diante do teclado a começar 
a digitar. Quanto a isso, nem mesmo há garantia de que haja alguém lá. Para fazer o retor- 
no rápido exigido, do read (linha 13953) começa armazenando informações que permitirão 
concluir posteriormente a requisição, quando e se a entrada chegar. Existem algumas veri- 
ficações de erro a serem feitas primeiro. É um erro se o dispositivo ainda estiver esperando 
entrada para atender uma requisição anterior ou se os parâmetros da mensagem forem invá- 
lidos (linhas 13964 a 13972). Se passar por esses testes, as informações sobre a requisição 
serão copiadas nos campos corretos da entrada tp->tty table do dispositivo, nas linhas 13975 
a 13979. O último passo, configurar tp->tty inleft com o número de caracteres solicitados, é 
importante. Essa variável é usada para determinar quando a requisição de leitura é atendida. 
No modo canônico, tp->tty inleft é decrementada por um para cada caractere retornado, até 
que um fim de linha seja recebido, quando ela é repentinamente zerada. No modo não-canô- 
nico, ela é tratada de forma diferente, mas em qualquer caso, é reconfigurada com zero quan- 
do a chamada é atendida, seja por um tempo limite atingido, seja pela recepção de pelo menos 
o número mínimo de bytes solicitados. Quando tp->tty inleft chega a zero, uma mensagem 
de resposta é enviada. Conforme veremos, as mensagens de resposta podem ser geradas em 
vários lugares. Às vezes, é necessário verificar se um processo que está lendo ainda espera 
uma resposta; um valor diferente de zero para tp->tty inleft serve como um flag para esse 
propósito. 

No modo canônico, um dispositivo de terminal espera pela entrada até que o número 
de caracteres solicitados na chamada seja recebido ou que seja atingido o fim de uma linha 
ou do arquivo. O bit ICANON, na estrutura termios, é testado na linha 13981 para ver se o 
modo canônico está em vigor para o terminal. Se não estiver ativo, os valores MIN e TIME de 
termios são verificados para determinar a ação a ser adotada. 

Na Figura 3-31, vimos como MIN e TIME interagem para fornecer diferentes compor- 
tamentos para uma chamada de leitura. TIME é testado na linha 13983. Um valor igual à zero 
corresponde à coluna da esquerda na Figura 3-31 e, nesse caso, mais nenhum teste é neces- 
sário nesse ponto. Se TIME é diferente de zero, então MIN é testado. Se for zero, settimer 
será chamada para iniciar o temporizador que terminará a requisição de DEV READ após 
um atraso, mesmo que nenhum byte tenha sido recebido. Tp->tty min é configurada como 
1 aqui, para que a chamada termine imediatamente caso um ou mais bytes sejam recebidos 
antes do tempo limite. Nesse ponto, nenhuma verificação de entrada foi feita ainda; portanto, 
mais de um caractere já pode estar esperando para atender a requisição. Nesse caso, os ca- 
racteres que estiverem prontos, até o número especificado na chamada read, serão retornados 
assim que a entrada for encontrada. Se TIME e MIN forem diferentes de zero, o temporizador 
terá um significado diferente. Nesse caso, ele é usado como temporizador entre caracteres. 
Ele é iniciado somente depois que o primeiro caractere for recebido e é reiniciado após cada 
caractere sucessivo. Tp->tty_eotct conta caracteres no modo não-canônico e, se for zero na 
linha 13993, nenhum caractere foi recebido ainda e o temporizador entre bytes é iníbido. 
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Em qualquer caso, na linha 14001, in transfer é chamada para transferir os bytes que 
já estão na fila de entrada diretamente para o processo que está lendo. Em seguida, há uma 
chamada para handle events, a qual pode colocar mais dados na fila de entrada e que cha- 
ma in transfer novamente. Essa aparente duplicação de chamadas exige alguma explicação. 
Embora a discussão até aqui tenha sido em termos de entrada de teclado, do read está na 
parte independente de dispositivo do código e também atende a entrada de terminais remotos 
conectados por meio de linhas seriais. É possível que uma entrada anterior tenha preenchido 
o buffer de entrada RS-232 até o ponto onde a entrada foi inibida. A primeira chamada para 
in transfer não inicia o fluxo novamente, mas a chamada para handle events pode ter esse 
efeito. O fato de ela causar, então, uma segunda chamada para in transfer é apenas um bônus. 
O importante é garantir que o terminal remoto possa enviar novamente. Qualquer uma dessas 
chamadas pode resultar no atendimento da requisição e no envio da mensagem de resposta 
para o sistema de arquivos. Tp->tty. inleft é usada como um flag para ver se a resposta foi en- 
viada; se ela ainda for diferente de zero na linha 14004, do read gerará e enviará a mensagem 
de resposta. Isso é feito nas linhas 14013 a 14021. (Supomos aqui que não foi feito nenhum 
uso da chamada de sistema select e, portanto, não haverá nenhuma chamada para select retry 
na linha 14006). 

Se a requisição original especificasse uma leitura sem bloqueio, o sistema de arquivos 
seria instruído a passar um código de erro EAGAIN para o processo original que fez a chama- 
da. Se a chamada é uma leitura com bloqueio normal, o sistema de arquivos recebe um código 
SUSPEND, desbloqueando-o, mas dizendo para que deixe bloqueado o processo original que 
fez a chamada. Neste caso, o campo tp->tty inrepcode do terminal é configurado como RE- 
VIVE. Quando, e se, a operação read for satisfeita posteriormente, esse código será colocado 
na mensagem de resposta para o sistema de arquivos, para indicar que o processo original que 
fez a chamada foi colocado em repouso e precisa ser despertado. 

Do write (linha 14029) é semelhante à do read, porém mais simples, pois existem 
menos opções para se preocupar no tratamento de uma chamada de sistema write. São feitas 
verificações semelhantes àquelas de do read para ver se uma escrita anterior ainda não está 
em andamento e se os parâmetros da mensagem são válidos; em seguida, os parâmetros da 
requisição são copiados na estrutura tty. Então, handle events é chamada e tp->tty outleft é 
verificado para ver se o trabalho foi feito (linhas 14058 a 14060). Se assim for, uma mensa- 
gem de resposta já foi enviada por handle events e não resta mais nada a fazer. Caso contrá- 
rio, uma mensagem de resposta é gerada, com os parâmetros da mensagem dependendo da 
chamada write original ter sido feita ou não no modo sem bloqueio. 

A próxima função, do ioctl (linha 14079), apesar de longa, não é difícil de entender. O 
miolo de do ioctl são dois comandos switch. A primeira determina o tamanho do parâmetro 
apontado pelo ponteiro na mensagem de requisição (linhas 14094 a 14125). Se o tamanho 
não for zero, a validade do parâmetro é testada. O conteúdo não pode ser testado aqui, mas o 
que pode ser testado é se uma estrutura do tamanho exigido, começando no endereço espe- 
cificado, cabe dentro do segmento em que deve estar. O restante da função é outro comando 
switch para o tipo de operação ioctl solicitada (linhas 14128 a 14225). 

Infelizmente, suportar as operações exigidas pelo POSIX com a chamada ioctl signi- 
ficou que tiveram de ser inventados nomes para as operações ioctl que sugerem, mas não 
duplicam, os nomes exigidos pelo POSIX. A Figura 3-39 mostra o relacionamento entre os 
nomes POSIX e os usados pela chamada ioctl do MINIX 3. Uma operação TCGETS atende 
uma chamada de tcgetattr feita pelo usuário e simplesmente retorna uma cópia da estrutura 
tp->tty termios do dispositivo de terminal. Os quatro tipos de requisições seguintes com- 
partilham código. Os tipos de requisições TCSETSW, TCSETSF e TCSETS correspondem 
às chamadas de usuário para a função tcsetattr definida pelo POSIX e todos têm a ação 
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básica de copiar uma nova estrutura termios na estrutura tty de um terminal. A cópia é feita 
imediatamente para chamadas de TCSETS e podem ser feitas para chamadas de TCSETSW e 
TCSETSF, caso a saída esteja concluída, por uma chamada de núcleo sys vircopy para obter 
os dados do usuário, seguida de uma chamada para setattr, nas linhas 14153 a 14156. Se 
tcsetattr foi chamada com um modificador solicitando o adiamento da ação até a conclusão 
da saída corrente, os parâmetros da requisição são colocados na estrutura tty do terminal para 
processamento posterior, caso o teste de tp->tty outleft, na linha 14139, revele que a saída 
não está concluída. Tcdrain suspende um programa até que a saída esteja concluída e é trans- 
formada em uma chamada ioctl de tipo TCDRAIN. Se a saída já estiver concluída, ela não tem 
mais nada a fazer. Se a saída não estiver concluída, ela também deverá deixar informações na 
estrutura tty. 


Função do POSIX Operação POSIX Tipo de IOCTL Parâmetro IOCTL 
tcdrain (nenhuma) TCDRAIN (nenhum) 

tcflow TCOOFF TCFLOW int=TCOOFF 
tcflow TCOON TCFLOW int=TCOON 
tcflow TCIOFF TCFLOW int=TCIOFF 
tcflow TCION TCFLOW int=TCION 
tcflush TCIFLUSH TCFLSH int=TCIFLUSH 
tcflush TCOFLUSH TCFLSH int=TCOFLUSH 
tcflush TCIOFLUSH TCFLSH int=TCIOFLUSH 
tcgetattr (nenhuma) TCGETS termios 

tcsetattr TCSANOW TCSETS termios 

tcsetattr TCSADRAIN TCSETSW termios 

tcsetattr TCSAFLUSH TCSETSF termios 
tcsendbreak (nenhuma) TCSBRK int=duração 


Figura 3-39 Chamadas do POSIX e operações IOCTL. 


A função tcflush do POSIX descarta dados de entrada não lidos e/ou de saída não en- 
viados, de acordo com seu argumento, e a transformação de ioctl é simples, consistindo em 
uma chamada para a função tty icancel que atende todos os terminais e/ou para a função es- 
pecífica do dispositivo apontada por tp->!ty ocancel (linhas 14159 a 14167). Analogamente, 
tcflow é transformada de maneira direta para uma chamada ioctl. Para suspender ou reiniciar 
a saída, ela configura um valor TRUE ou FALSE em tp->tty inhibited e, então, ativa o flag 
tp->tty events. Para suspender ou reiniciar a entrada, ela envia o código STOP (normalmente, 
CTRL-S) ou START (CTRL-Q) apropriado para o terminal remoto, usando a rotina de eco 
específica do dispositivo apontada por tp->tty echo (linhas 14181 a 14186). 

A maior parte do restante das operações manipuladas por do ioctl é tratada em uma 
única linha de código, chamando uma função apropriada. Nos casos das operações KIOCS- 
MAP (carregar mapas de teclado) e TIOCSFON (carregar fonte), é feito um teste para garantir 
que o dispositivo seja realmente um console, pois essas operações não se aplicam aos outros 
terminais. Se terminais virtuais estiverem em uso, os mesmos mapas de teclado e fonte se 
aplicarão a todos consoles; o hardware não permite nenhum outro modo de fazer isso de 
forma diferente. As operações de tamanho de janela copiam uma estrutura winsize entre o 
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processo de usuário e o driver de terminal. Observe, entretanto, o comentário sob o código da 
operação TIOCSWINSZ. Em algumas versões do UNIX, quando um processo altera seu ta- 
manho de janela, espera-se que o núcleo envie um sinal SIGWINCH para o grupo do proces- 
so. O sinal não é exigido pelo padrão POSIX e não é implementado no MINIX 3. Entretanto, 
quem estiver pensando em usar essas estruturas deve considerar a adição do código aqui, para 
iniciar esse sinal. 

Os dois últimos casos em do ioctl suportam as funções tcgetpgrp e tcsetpgrp exigidas 
pelo POSIX. Não há nenhuma ação associada a esses casos e as funções sempre retornam um 
erro. Não há nenhum problema nisso. Essas funções suportam controle de jobs, a capacidade 
de suspender e reiniciar um processo a partir do teclado. O controle de jobs não é exigido pelo 
POSIX e não é suportado pelo MINIX 3. Entretanto, o POSIX exige essas funções, mesmo 
quando o controle de jobs não é suportado, para garantir a portabilidade dos programas. 

Do open (linha 14234) tem uma ação básica simples para executar — ela incrementa a 
variável tp->tty openct do dispositivo para que possa ser verificado se ele está aberto. Entre- 
tanto, existem alguns testes a serem feitos primeiro. O POSIX especifica que, para terminais 
normais, o primeiro processo a abrir um terminal é o líder da sessão. Quando um líder de 
sessão é extinto, o acesso ao terminal é retirado dos demais processos que fazem parte de seu 
grupo. Os daemons precisam ser capazes de escrever mensagens de erro e, se sua saída de 
erro não for redirecionada para um arquivo, ela deve ir para um monitor que não possa ser 
fechado. 

Para esse propósito, existe no MINIX 3 um dispositivo chamado /dev/log. Fisicamente, 
é o mesmo dispositivo que /dev/console, mas é endereçado por um número secundário de 
dispositivo separado e é tratado de forma diferente. Trata-se de um dispositivo somente para 
escrita e, assim, do open retornará o erro EACCESS se for feita uma tentativa de abri-lo para 
leitura (linha 14246). O outro teste feito por do open é para o flag O NOCTTY. Se ele não 
estiver ativo e o dispositivo não for /dev/log, o terminal torna-se o terminal controlador para 
um grupo de processos. Isso é feito colocando-se o número do processo que fez a chamada 
no campo tp->tty pgrp da entrada tty table. Depois disso, a variável tp->tty openct é incre- 
mentada e a mensagem de resposta é enviada. 

Um dispositivo de terminal pode ser aberto mais de uma vez e a função seguinte, 
do close (linha 14260), não tem nada a fazer, exceto decrementar tp->tty openct. O teste 
feito na linha 14266 frustra uma tentativa de fechar o dispositivo, caso ele seja /dev/log. Se 
essa operação for o último fechamento, a entrada é cancelada pela chamada de tp->tty icancel. 
Também são chamadas rotinas específicas do dispositivo apontadas por tp->tty ocancel e 
tp->tty close. Então, vários campos na estrutura tty do dispositivo são reconfigurados com 
seus valores padrão e a mensagem de resposta é enviada. 

A última rotina de tratamento de tipo de mensagem que consideraremos é do cancel 
(linha 14281). Ela é ativada quando um sinal é recebido por um processo que está bloqueado 
tentando ler ou escrever. Existem três estados que devem ser verificados: 


1. O processo poderia estar lendo quando foi eliminado. 
2. O processo poderia estar escrevendo quando foi eliminado. 


3. O processo poderia estar suspenso por tcdrain até que sua saída estivesse con- 
cluída. 


É feito um teste para cada caso e a rotina geral tp->tty. icancel, ou a rotina específica do 
dispositivo, apontada por tp->tty ocancel, é chamada, conforme for necessário. No último 
caso, a única ação exigida é desativar o flag tp->tty ioreq para indicar que, agora, a operação 
ioctl está terminada. Finalmente, o flag tp->tty events é ativado e uma mensagem de resposta 
é enviada. 
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Código de suporte ao driver de terminal 


Agora que já vimos as funções de nível superior chamadas no laço principal de tty task, 
é hora de examinarmos o código que as suporta. Começaremos com handle events (linha 
14358). Conforme mencionado anteriormente, em cada passagem pelo laço principal do 
driver de terminal, o flag tp->tty events de cada dispositivo de terminal é verificado e 
handle events é chamada caso ele mostre que é exigida atenção para um terminal em par- 
ticular. Do read e do write também chamam handle events. Essa rotina precisa trabalhar 
rápido. Ela desativa o flag tp->tty events e depois chama rotinas específicas do dispositivo 
para ler e escrever, usando os ponteiros para as funções tp->tty devread e tp->tty devwrite 
(linhas 14382 a 14385). 

Essas funções são chamadas incondicionalmente, pois não há como testar se uma lei- 
tura ou uma escrita ativou o flag — foi feita uma escolha de projeto aqui, pois verificar dois 
flags para cada dispositivo seria mais dispendioso do que fazer duas chamadas sempre que 
um dispositivo estivesse ativo. Além disso, na maioria das vezes, um caractere recebido de 
um terminal deve ser ecoado; portanto, as duas chamadas serão necessárias. Conforme ob- 
servado na discussão sobre o tratamento das chamadas de tcsetattr por do ioctl, o POSIX 
pode adiar operações de controle nos dispositivos até que a saída corrente tenha terminado; 
portanto, imediatamente após chamar a função tty devwrite específica do dispositivo é um 
bom momento para cuidar das operações de ioctl. Isso é feito na linha 14388, onde dev ioctl 
é chamada se houver uma requisição de controle pendente. 

Como o flag tp->tty events é ativado por interrupções e como os caracteres podem che- 
gar de um dispositivo rápido, existe a chance de que, quando as chamadas para as rotinas de 
leitura e escrita específicas do dispositivo e dev ioctl tiverem terminado, outra interrupção te- 
nha ativado o flag novamente. É dada uma alta prioridade para a retirada da entrada do buffer, 
onde a rotina de interrupção a colocou inicialmente. Assim, handle events repete as chama- 
das para as rotinas específicas do dispositivo, desde que o flag tp->tty events seja encontrado 
ativo no final do laço (linha 14389). Quando o fluxo de entrada pára (também poderia ser 
o de saída, mas é mais provável que a entrada faça tais exigências repetidas), in transfer é 
chamada para transferir caracteres da fila de entrada para o buffer do processo que solicitou a 
requisição de leitura. A própria função in transfer envia a mensagem de resposta se a trans- 
ferência concluir a requisição, seja transferindo o número máximo de caracteres solicitados 
ou encontrando o final de uma linha (no modo canônico). Se ela fizer isso, tp->tty left será 
zero no retorno para handle events. Aqui, mais um teste é feito e uma mensagem de resposta 
é enviada se o número de caracteres transferidos tiver atingido o número mínimo solicitado. 
Testar tp->tty inleft impede o envio de uma mensagem duplicada. 

A seguir, veremos in transfer (linha 14416), que é responsável por mover dados da fila 
de entrada no espaço de memória do driver para o buffer do processo de usuário que solicitou 
a entrada. Entretanto, uma cópia de bloco simples não é possível aqui. A fila de entrada é um 
buffer circular e os caracteres precisam ser verificados para ver se o final do arquivo não foi 
atingido ou, se o modo canônico estiver em vigor, se a transferência simplesmente continua 
até o fim de uma linha. Além disso, a fila de entrada tem quantidades de 16 bits, mas o buffer 
do destinatário é um array de caracteres representados em 8 bits. Assim, é usado um buffer 
local intermediário. Os caracteres são verificados um a um, à medida que são colocados no 
buffer local, e quando o buffer for preenchido, ou quando a fila de entrada estiver vazia, 
sys. vircopy será chamada para mover o conteúdo do buffer local para o buffer do processo 
receptor (linhas 14432 a 14459). 

São usadas três variáveis na estrutura tty, tp->tty inleft, tp->tty eotct e tp->tty min, 
para decidir se in transfer tem algum trabalho a fazer, e as duas primeiras controlam seu 
laço principal. Conforme mencionado anteriormente, tp->tty inleft é configurada inicial- 
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mente com o número de caracteres solicitados por uma chamada read. Normalmente, ela é 
decrementada por um quando um caractere é transferido, mas pode ser posta abruptamente 
para zero, quando uma condição sinalizando o fim da entrada é atingida. Ao atingir zero, é 
gerada uma mensagem de resposta para o leitor; portanto, ela também serve como um flag 
para indicar se uma mensagem foi enviada ou não. Assim, no teste da linha 14429, verificar 
se tp->tty inleft é zero é um motivo suficiente para cancelar a execução de in transfer sem 
enviar uma resposta. 

Na parte seguinte do teste, tp->tty eotct e tp->tty min são comparadas. No modo ca- 
nônico, essas duas variáveis se referem a linhas de entrada completas e no modo não-ca- 
nônico elas se referem a caracteres. Tp->tty eotct é incrementada quando uma “quebra de 
linha” ou um byte é colocado na fila de entrada e é decrementada por in transfer, quando 
uma linha ou um byte é removido da fila. Em outras palavras, ela conta o número de linhas 
ou bytes recebidos pelo driver de terminal, mas que ainda não foram passados para um 
leitor. Tp->tty min indica o número mínimo de linhas (no modo canônico) ou os caracteres 
(no modo não-canônico) que devem ser transferidos para concluir uma requisição de leitu- 
ra. Seu valor é sempre 1 no modo canônico e pode ser qualquer valor de O a MAX INPUT 
(255, no MINIX 3) no modo não-canônico. A segunda metade do teste na linha 14429 faz 
in transfer retornar imediatamente no modo canônico, caso uma linha completa ainda não 
tenha sido recebida. A transferência não é feita até que uma linha esteja completa, de modo 
que o conteúdo da fila pode ser modificado se, por exemplo, um caractere ERASE ou KILL 
for digitado subsegiientemente pelo usuário, antes que a tecla ENTER seja pressionada. No 
modo não-canônico, ocorrerá um retorno imediato se o número mínimo de caracteres ainda 
não estiver disponível. 

Algumas linhas mais adiante, tp->tty inlefte tp->tty eotct são usadas para controlar o 
laço principal de in transfer. No modo canônico, a transferência continua até que não reste 
mais nenhuma linha completa na fila. No modo não-canônico, tp->tty eotct contabiliza os 
caracteres pendentes. Tp->tty min controla se o laço é iniciado, mas não é usada para deter- 
minar quando parar. Uma vez iniciado o laço, são transferidos todos os caracteres disponíveis 
no momento ou o número de caracteres solicitados na chamada original, o que for menor. 

Os caracteres são quantidades de 16 bits na fila de entrada. O código de caractere real a 
ser transferido para o processo de usuário é dado nos 8 bits inferiores. A Figura 3-40 mostra 
como os bits superiores são usados. Três são usados para sinalizar se o caractere tem escape 
(por meio de CTRL-V), se significa fim de arquivo ou se representa um dos vários códigos 
que indicam que uma linha está completa. Quatro bits são usados para fornecer o número de 
espaços usados na tela quando o caractere for ecoado. O teste na linha 14435 verifica se o bit 
IN EOF (D, na figura) está ativado. Isso é testado no início do laço interno, pois um fim de 
arquivo (CTRL-D) em si não é transferido para um leitor nem computado na contagem de 
caracteres. À medida que cada caractere é transferido, uma máscara é aplicada para zerar os 
8 bits superiores e apenas o valor ASCII nos 8 bits inferiores é transferido para o buffer local 
(linha 14437). 

Há mais de uma maneira de sinalizar o fim da entrada, mas a rotina de entrada específica 
do dispositivo é que deve determinar se um caractere recebido é um avanço de linha, CTRL-D 
ou outro caractere desse tipo, e marcar cada caractere. In transfer só precisa testar essa marca, 
o bit IN EOT(N, na Figura 3-40), na linha 14454. Se isso for detectado, tp->tty eotct será 
decrementada. No modo não-canônico, todo caractere é contado dessa maneira ao ser coloca- 
do na fila de entrada e todo caractere também é marcado nesse momento com o bit IN EOT, 
de modo que 1p->tty eotct fornece a quantidade de caracteres ainda não removidos da fila. 
A única diferença na operação do laço principal de in transfer nos dois modos diferentes é 
encontrada na linha 14457. Aqui, tp->tty inleft é zerada em resposta ao fato de um caractere 
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olv[o|nfe[clclc[7z[e[s[|4[alJz[1To 


V: IN_ESC, escape com LNEXT (CTRL-V) 

D: IN_EOF, fim de arquivo (CTRL-D) 

N: IN_EOT, quebra de linha (NL e outros) 

Cccc: contagem de caracteres ecoados 

de Bit 7, pode ser zerado, se ISTRIP estiver ativo 
6-0: Bits 0-6, código ASCII 


Figura 3-40 Os campos em um código de caractere, conforme ele é colocado na fila de 
entrada. 


marcado como quebra de linha ter sido encontrado, mas apenas se o modo canônico estiver 
em vigor. Assim, quando o controle retorna para o início do laço, o laço termina corretamente 
após uma quebra de linha no modo canônico, mas no modo não-canônico, as quebras de linha 
são ignoradas. 

Quando o laço termina, normalmente há um buffer local parcialmente preenchido para 
ser transferido (linhas 14461 a 14468). Então, uma mensagem de resposta será enviada, se 
tp->tty inleft tiver chegado a zero. Isso sempre acontece no modo canônico, mas se o modo 
não-canônico estiver em vigor e o número de caracteres transferidos for menor do que a 
requisição completa, a resposta não será enviada. Isso pode ser confuso, se você tiver boa me- 
mória para detalhes a ponto de lembrar que, quando vimos as chamadas para in transfer (em 
do read e handle events), o código após a chamada para in transfer enviava uma mensagem 
de resposta, se in transfer retornasse tendo transferido mais do que a quantidade especificada 
em 1p->tty min, o que certamente acontecerá aqui. O motivo pelo qual uma resposta não é 
dada incondicionalmente a partir de in transfer será visto quando discutirmos a próxima 
função, que chama in transfer sob um conjunto de circunstâncias diferentes. 

A próxima função é in process (linha 14486). Ela é chamada a partir do software espe- 
cífico do dispositivo, para tratar do processamento comum que deve ser feito em toda entrada. 
Seus parâmetros são um ponteiro para a estrutura tty do dispositivo de origem, um ponteiro 
para o array de caracteres de 8 bits a ser processado e uma quantidade. A quantidade é retor- 
nada para o processo que fez a chamada. In process é uma função comprida, mas suas ações 
não são complicadas. Ela adiciona caracteres de 16 bits na fila de entrada que, posteriormen- 
te, é processada por in transfer. 

Existem várias categorias de tratamento fornecidas por in transfer. 


1. Os caracteres normais são adicionados na fila de entrada, estendidos para 16 bits. 


2. Os caracteres que afetam o processamento posterior modificam flags para sinalizar 
o efeito, mas não são colocados na fila. 


3. Os caracteres que controlam o eco têm efeito imediato, sem serem colocados na 
fila. 


4. Os caracteres com significado especial têm códigos, como o bit EOT, adicionados 
em seus bytes superiores, à medida que são colocados na fila de entrada. 


Vamos ver primeiro uma situação completamente normal: um caractere comum, como 
“x” (código ASCII 0x78), digitado no meio de uma linha curta, sem nenhuma seqiiência de 
escape vigorando, em um terminal configurado com as propriedades padrão do MINIX 3. 
Quando é recebido do dispositivo de entrada, esse caractere ocupa os bits de O a 7 na Figura 
3-40. Na linha 14504, ele teria seu bit mais significativo, o bit 7, posto como zero, se o bit 
ISTRIP estivesse ativo, mas o padrão no MINIX 3 é não retirar o bit, permitindo a entrada 
de códigos de 8 bits completos. De qualquer modo, isso não afetaria nosso “x”. O padrão do 
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MINIX 3 é permitir o processamento estendido da entrada; portanto, o teste do bit ZJEXTEN 
em tp->tty termios.c lflag (linha 14507) é aprovado, mas os testes seguintes falham sob as 
condições que postulamos: nenhum escape de caractere está em vigor (linha 14510), essa 
entrada não é o caractere de escape de caractere (linha 14517) e também não é o caractere 
REPRINT (linha 14524). 

Os testes nas linhas seguintes verificam se o caractere de entrada não é o caractere 
especial POSIX VDISABLE nem CR ou NL. Finalmente, um resultado positivo: o modo 
canônico está em vigor; esse é o padrão normal (linha 14324). Entretanto, nosso “x” não é o 
caractere ERASE, tampouco é KILL, EOF (CTRL-D), NL ou EOL,; portanto, na linha 14576 
nada ainda terá acontecido com ele. Aqui, se descobre que o bit IXON está ativo (por padrão) 
permitindo o uso dos caracteres STOP (CTRL-S) e START (CTRL-Q), mas nos testes seguin- 
tes para eles, nenhuma correspondência é encontrada. Na linha 14597, descobre-se que o bit 
ISIG, que permite o uso dos caracteres INTR e QUIT, está ativo por padrão, mas, novamente, 
nenhuma correspondência é encontrada. 

Na verdade, a primeira coisa interessante que poderia acontecer com um caractere co- 
mum ocorre na linha 14610, onde é feito um teste para saber se a fila de entrada já está cheia. 
Se isso acontecesse, o caractere seria descartado nesse ponto, pois o modo canônico está 
vigorando, e o usuário não o veria ecoado na tela. (A instrução continue descarta o caractere, 
pois ela faz o laço externo reiniciar). Entretanto, como postulamos condições completamente 
normais para esta ilustração, vamos supor que o buffer ainda não esteja cheio. O próximo 
teste, para ver se é necessário processamento especial do modo não-canônico (linha 14616), 
falha, causando um salto para frente, até a linha 14629. Aqui, echo é chamada para mostrar o 
caractere para o usuário, pois o bit ECHO em tp->tty termios.c Iflag é ativado por padrão. 

Finalmente, nas linhas 14632 a 14636, o caractere é utilizado, sendo colocado na fila de 
entrada. Nesse momento, tp->tty incount é incrementado, mas como se trata de um caractere 
comum, não marcado pelo bit EOT, tp->tty eotct não é alterada. 

A última linha no laço chama in transfer se o caractere que acabou de ser transfe- 
rido lotar a fila. Entretanto, sob as condições normais que postulamos para este exemplo, 
in transfer não faria nada, mesmo que fosse chamada, pois (supondo que a fila tenha sido 
servida normalmente e a entrada anterior tenha sido aceita quando a linha de entrada anterior 
estava completa) tp->tty eotct é zero, tp->tty min é 1 e o teste no início de in transfer (linha 
14429) causa um retorno imediato. 

Tendo passado por in process com um caractere comum sob condições normais, va- 
mos voltar agora para o início de in process e ver o que acontece em circunstâncias menos 
normais. Primeiramente, veremos o escape de caractere, que permite a um caractere que 
normalmente tem efeito especial passar para o processo de usuário. Se um escape de carac- 
tere está em vigor, o flag tp->tty escaped está ativado e, quando isso é detectado (na linha 
14510), o flag é desativado imediatamente e o bit IN ESC, bit V na Figura 3-40, é adicionado 
ao caractere corrente. Isso causa processamento especial quando o caractere é ecoado—os 
caracteres de controle com escape são exibidos como ““”, mais o caractere para torná-los 
visíveis. O bit IN ESC também impede que o caractere seja reconhecido pelos testes de ca- 
racteres especiais. 

As linhas seguintes processam o caractere de escape em si, o caractere LNEXT (CTRL- 
V, por padrão). Quando o código LNEXT é detectado, o flag tp->tty escaped é ativado e 
rawecho é chamada duas vezes para produzir a saída de “~, seguida de um retrocesso. Isso 
lembra o usuário que está no teclado de que um escape está vigorando e, quando o caractere 
seguinte é ecoado, ele sobrescreve o “~. LNEXT é um exemplo de caractere que afeta os ca- 
racteres posteriores (neste caso, apenas o próximo caractere). Ele não é colocado na fila e o 
laço recomeça após as duas chamadas para rawecho. A ordem desses dois testes é importante, 
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tornando possível inserir o próprio caractere LNEXT duas vezes em seqiiência, para passar a 
segunda cópia como dados reais para um processo. 

O próximo caractere especial processado por in process é REPRINT (CTRL-R). Quan- 
do ele é encontrado, ocorre uma chamada para reprint (linha 14525), fazendo com que a saída 
ecoada corrente seja reapresentada. Então, o caractere REPRINT em si é descartado, sem 
nenhum efeito sobre a fila de entrada. 

Entrar nos detalhes sobre o tratamento de cada caractere especial seria maçante e o 
código-fonte de in process é simples. Mencionaremos apenas mais alguns pontos. Um deles 
é que o uso de bits especiais no byte superior do valor de 16 bits colocado na fila de entrada 
torna fácil identificar uma classe de caracteres que têm efeitos semelhantes. Assim, EOT 
(CTRL-D), LF e o caractere alternativo EOL (indefinido por padrão) são todos marcados 
pelo bit EOT, o bit D na Figura 3-40 (linhas 14566 a 14573), facilitando o reconhecimento 
posterior. 

Finalmente, justificaremos o comportamento peculiar de in transfer observado ante- 
riormente. Não é gerada uma resposta sempre que ela termina, embora nas chamadas para 
in transfer que vimos anteriormente, parecia que uma resposta sempre seria gerada no re- 
torno. Lembre-se de que a chamada para in transfer feita por in process quando a fila de 
entrada está cheia (linha 14639) não tem nenhum efeito quando o modo canônico está vi- 
gorando. Mas, se for desejado processamento não-canônico, cada caractere será marcado 
com o bit EOT na linha 14618 e, assim, cada caractere será contado por tp->tty eotct na 
linha 14636. Por sua vez, isso causa a entrada no laço principal de in transfer quando ela 
é chamada por causa de uma fila de entrada cheia no modo não-canônico. Nessas ocasiões, 
nenhuma mensagem deve ser enviada no término de in transfer, pois provavelmente haverá 
mais caracteres lidos após retornar para in process. Na verdade, embora a entrada no modo 
canônico para uma única operação read seja limitada pelo tamanho da fila de entrada (255 
caracteres, no MINIX 3), no modo não-canônico, uma chamada read deve ser capaz de en- 
viar o número de caracteres constante POSIX SSIZE MAX exigido pelo POSIX. Seu valor 
no MINIX 3 é 32767. 

As próximas funções em tty.c suportam entrada de caractere. Tty echo (linha 14647) 
trata alguns caracteres de maneira especial, mas a maioria é simplesmente exibida no lado da 
saída do mesmo dispositivo que está sendo usado para entrada. A saída de um processo pode 
estar indo para um dispositivo ao mesmo tempo em que a entrada está sendo ecoada, o que 
torna as coisas complicadas se o usuário que estiver no teclado tentar retroceder. Para tratar 
disso, o flag tp->tty reprint é sempre configurado como TRUE pelas rotinas de saída espe- 
cíficas do dispositivo para uma saída normal. Dessa forma, a função que trata o retrocesso 
pode identificar que foi produzida uma saída mista. Como tty echo também usa as rotinas de 
saída do dispositivo, o valor corrente de tp->tty reprint é preservado durante o eco, usando a 
variável local rp (linhas 14668 a 14701). Entretanto, se uma nova linha de entrada acabou de 
começar, rp é configurada como FALSE, em vez de assumir o valor antigo, garantindo assim 
que tp->tty reprint seja reconfigurado quando echo terminar. 

Talvez você tenha notado que tty echo retorna um valor, por exemplo, na chamada da 
linha 14629 em in process: 


ch=tty echo(tp, ch) 


O valor retornado por echo contém o número de espaços usados na tela para exibição do 
eco, que pode ser até oito, se o caractere for TAB. Essa contagem é colocada no campo cccc 
na Figura 3-40. Os caracteres normais ocupam um único espaço na tela, mas se um caractere 
de controle (que não seja TAB, NL ou CR) ou um DEL (0x7F) for ecoado, ele será exibido 


6693 


como “^”, mais um caractere ASCII imprimível, e ocupará duas posições na tela. Por outro 
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lado, um NL ou CR não ocupa nenhum espaço. É claro que o eco deve ser feito por uma ro- 
tina específica do dispositivo e, quando um caractere precisa ser passado para o dispositivo, 
é feita uma chamada indireta usando tp->tty echo, como, por exemplo, na linha 14696, para 
caracteres normais. 

A próxima função, rawecho, é usada para evitar o tratamento especial feito por echo. 
Ela verifica se o flag ECHO está ativo e, se estiver, envia o caractere para a rotina específica 
do dispositivo tp->tty echo, sem qualquer processamento especial. Uma variável local rp é 
usada aqui, para impedir que a própria chamada de rawecho para a rotina de saída altere o 
valor de tp->tty reprint. 

Quando um retrocesso é encontrado por in process, a próxima função, back over (li- 
nha 14721), é chamada. Ela manipula a fila de entrada para remover o início da fila anterior, 
se for possível retroceder — se a fila estiver vazia ou se o último caractere for uma quebra de 
linha, então o retrocesso não será possível. Aqui, é testado o flag tp->tty reprint, mencionado 
nas discussões sobre echo e rawecho. Se ele for TRUE, então reprint será chamada (linha 
14732) para colocar uma cópia da linha de saída na tela. Em seguida, o campo len do último 
caractere exibido (o campo cccc da Figura 3-40) é consultado para se descobrir quantos ca- 
racteres precisam ser excluídos na tela e, para cada caractere, uma segiiência de caracteres de 
retrocesso-espaço-retrocesso é enviada por rawecho para remover o caractere indesejado da 
tela e substituí-lo por um espaço. 

Reprint é a função seguinte. Além de ser chamada por back over, ela pode ser ativada 
pelo usuário pressionando a tecla REPRINT (CTRL-R). O laço nas linhas 14764 a 14769 
faz uma pesquisa para trás na fila de entrada, em busca da última quebra de linha. Se ela for 
encontrada na última posição preenchida, não haverá nada para fazer e reprint retornará. 
Caso contrário, ela ecoará o CTRL-R, que aparece no monitor como a seqiiência de dois 
caracteres “^R”, e depois irá para a linha seguinte e reapresentará a fila da última quebra de 
linha até o final. 

Agora, chegamos a out process (linha 14789). Assim como in process, ela é chama- 
da por rotinas de saída específicas do dispositivo, mas é mais simples. Ela é chamada pelas 
rotinas de saída específicas de dispositivos RS-232 e pseudoterminal, mas não pela rotina 
de console. Out process trabalha sobre um buffer circular de bytes, mas não os remove do 
buffer. A única alteração que ela faz no array é inserir um caractere CR na frente de um ca- 
ractere NL no buffer, caso os bits OPOST (ativar processamento de saída) e ONLCR (fazer o 
mapeamento de NL para CR-NL) em 1p->tty termios.oflag estejam ativos. Esses dois bits são 
ativados por padrão no MINIX 3. Sua tarefa é manter a variável tp->tty position atualizada 
na estrutura tty do dispositivo. Tabulações e retrocessos complicam a vida. 

A rotina seguinte é dev ioctl (linha 14874). Ela apóia do ioctl na execução da fun- 
ção tcdrain e da função tcsetattr, quando é chamada com as opções TCSADRAIN ou 
TCSAFLUSH. Nesses casos, do ioctl não pode completar a ação imediatamente, caso a saída 
esteja incompleta; portanto, informações sobre a requisição são armazenadas nas partes da 
estrutura tty reservadas para operações ioctl postergadas. Quando handle events é executada, 
ela primeiro verifica o campo tp->tty ioreq, após chamar a rotina de saída específica do dis- 
positivo, e chama dev ioctl se uma operação estiver pendente. Dev ioctl testa tp->tty outleft 
para ver se a saída está concluída e, se estiver, executa as mesmas ações que do ioctl teria 
executado imediatamente, caso não houvesse nenhum atraso. Para atender tcdrain, a única 
ação é reconfigurar o campo tp->tty ioreg e enviar a mensagem de resposta para o sistema de 
arquivos, dizendo a ele para que desperte o processo que fez a chamada original. A variante 
TCSAFLUSH de tcsetattr chama tty icancel para cancelar a entrada. Para as duas variantes 
de tcsetattr, a estrutura termios cujo endereço foi passado na chamada original para ioctl é 
copiada na estrutura tp->tty termios do dispositivo. Então, setattr é chamada, seguida, assim 
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como acontece com tcdrain, pelo envio de uma mensagem de resposta para despertar o pro- 
cesso bloqueado que fez a chamada original. 

Setattr (linha 14899) é a função seguinte. Como vimos, ela é chamada por do ioctl ou 
por dev ioctl para alterar os atributos de um dispositivo de terminal e por do close para re- 
configurar os atributos novamente com o padrão. Setattr é sempre chamada após copiar uma 
nova estrutura termios na estrutura tty do dispositivo, pois copiar apenas os parâmetros não 
é suficiente. Se o dispositivo que está sendo controlado estiver agora no modo não-canônico, 
a primeira ação será marcar todos os caracteres correntemente na fila de entrada com o bit 
IN EOT, como seria feito quando esses caracteres fossem originalmente inseridos na fila se 
o modo não-canônico estivesse em vigor. É mais fácil apenas ir em frente e fazer isso (linhas 
14913 a 14919) do que testar se os caracteres já têm o bit ativado. Não há como saber quais 
atributos acabaram de ser alterados e quais ainda mantêm seus valores antigos. 

A próxima ação é verificar os valores de MIN e TIME. No modo canônico, tp->tty min 
é sempre 1, que é configurado na linha 14926. No modo não-canônico, a combinação dos 
dois valores possibilita quatro modos de operação diferentes, conforme vimos na Figura 3- 
31. Nas linhas 14931 a 14933, tp->tty min primeiro é configurada com o valor passado em 
tp->tty termios.cc[VMIN], que, então, é modificado se for zero e tp->tty termios.cc[VTIME] 
não for zero. 

Finalmente, setattr garante que a saída não seja interrompida, caso o controle XON/ 
XOFF esteja desativado; envia um sinal SIGHUP, se a velocidade de saída for configurada 
como zero; e faz uma chamada indireta para a rotina específica do dispositivo apontada por 
tp->tty ioctl, para fazer o que só pode ser feito no nível do dispositivo. 

A próxima função, tty reply (linha 14952), foi mencionada muitas vezes na discussão 
anterior. Sua ação é muito simples: construir uma mensagem e enviá-la. Se, por algum moti- 
vo, a resposta falhar, resultará uma situação de pânico. As funções seguintes são igualmente 
simples. Sigchar (linha 14973) pede para que o gerenciador de memória (Memory Manager 
— MM) envie um sinal. Se o flag NOFLSH não estiver ativo, a entrada enfileirada será remo- 
vida — a contagem de caracteres ou linhas recebidas será zerada e os ponteiros para o final e 
para o início da fila serão igualados. Essa é a ação padrão. Quando um sinal SIGHUP precisa 
ser capturado, NOFLSH pode ser ativado para permitir a retomada da entrada e da saída após 
a captura do sinal. Tty icancel (linha 15000) descarta incondicionalmente a entrada penden- 
te da maneira descrita para sigchar e, além disso, chama a função específica do dispositivo 
apontada por tp->tty icancel para cancelar a entrada que possa existir no próprio dispositivo 
ou que esteja em buffer no código de baixo nível. 

Tty init (linha 15013) é chamada quando tty task é iniciada pela primeira vez. Ela faz 
um laço por todos os terminais possíveis e configura os padrões. Inicialmente, um ponteiro 
para tty devnop, uma função fictícia que não faz nada, é configurado nas variáveis 1p->tty 
icancel, tp->tty ocancel, tp->tty iocile tp->tty close. Então, tty init chama as funções de 
inicialização específicas do dispositivo para a categoria de terminal apropriada (console, 
linha serial ou pseudoterminal). Essas funções configuram os ponteiros reais para as funções 
específicas do dispositivo chamadas indiretamente. Lembre-se de que, se não houver dispo- 
sitivo configurado em uma categoria de dispositivo em particular, uma macro que retorna 
imediatamente será criada; portanto, nenhuma parte do código para um dispositivo não con- 
figurado precisará ser compilada. A chamada para scr. init inicializa o driver de console e 
também chama a rotina de inicialização do teclado. 

As próximas três funções suportam temporizadores. Um temporizador de cão de guarda 
é inicializado com um ponteiro para uma função a ser executada quando o tempo expirar. 
Tty timed out é essa função para a maioria dos temporizadores configurados pela tarefa de 
terminal. Ela configura o flag de eventos para obrigar o processamento de entrada e saída. Ex- 
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pire timers manipula a fila de temporizadores do driver de terminal. Lembre-se de que essa é 
a função chamada a partir do laço principal de tty task, quando uma mensagem SYN ALARM 
é recebida. Uma rotina de biblioteca, tmrs exptimers, é usada para percorrer a lista encadeada 
de temporizadores, expirando e chamando as funções de cão de guarda de qualquer um que 
tenha atingido o tempo limite. No retorno da função de biblioteca, se a fila ainda estiver ativa, 
é feita uma chamada de núcleo sys setalarm para solicitar outra mensagem SYN ALARM. 
Finalmente, settimer (linha 15089), configura temporizadores para determinar quando deve 
retornar de uma chamada read no modo não-canônico. Ela é chamada com parâmetros de 
tty ptr, um ponteiro para uma estrutura tty e enable, um valor inteiro que representa TRUE ou 
FALSE. As funções de biblioteca tmrs. settimer e tmrs. clrtimer são usadas para ativar ou de- 
sativar um temporizador, conforme determinado pelo argumento enable. Quando um tempo- 
rizador é ativado, a função de cão de guarda é sempre tty timed out, descrita anteriormente. 

Uma descrição de tty devnop (linha 15125) é necessariamente mais longa do que seu 
código executável, pois ela não tem nenhum. Ela é uma função “sem operação” para ser en- 
dereçada indiretamente quando um dispositivo não exigir serviço. Vimos tty devnop usada 
em tfy init como o valor padrão inserido em vários ponteiros de função, antes da chamada da 
rotina de inicialização de um dispositivo. 

O último item em tty.c precisa de alguma explicação. Select é uma chamada de sistema 
usada quando vários dispositivos de E/S podem exigir serviço em momentos imprevisíveis 
por parte de um único processo. Um exemplo clássico é um programa de comunicação que 
precisa prestar atenção a um teclado local e a um sistema remoto, talvez conectado por meio 
de um modem. A chamada select permite abrir vários arquivos de dispositivo e monitorar 
todos eles para ver quando podem ser lidos ou escritos sem bloquear. Sem select, é necessário 
usar dois processos para manipular a comunicação bilateral, um atuando como mestre, ma- 
nipulando a comunicação em uma direção, e o outro como escravo, manipulando a comuni- 
cação na outra direção. Select é um exemplo de recurso muito interessante de se ter, mas que 
complica substancialmente o sistema. Um dos objetivos de projeto do MINIX 3 é ser simples 
o suficiente para ser entendido com um esforço razoável, em um tempo também razoável, e 
temos de estabelecer alguns limites. Por isso, não discutiremos aqui do select (linha 15135) 
e as rotinas de suporte select try (linha 14313) e select retry (linha 14348). 


Implementação do driver de teclado 


Vamos ver agora o código dependente de dispositivo que suporta o console do MINIX 3, que 
consiste em um teclado de IBM PC e em um monitor mapeado me memória. Os dispositi- 
vos físicos que os suportam são totalmente separados: em um sistema de desktop padrão, o 
monitor usa uma placa adaptadora (da qual existem pelo menos meia dúzia de tipos básicos) 
conectada ao barramento, enquanto o teclado é suportado por circuitos incorporados à placa- 
mãe que interagem com um processador simples de 8 bits dentro da unidade de teclado. Os 
dois subdispositivos exigem suporte de software totalmente separado, o qual é encontrado 
nos arquivos keyboard.c e console.c. 

O sistema operacional vê o teclado e o console como partes do mesmo dispositivo, 
/dev/console. Se houver memória suficiente disponível no adaptador de vídeo, poderá ser 
compilado o suporte para console virtual e, além de /dev/console, poderão existir dispo- 
sitivos lógicos adicionais, /dev/ttyc1, /dev/ttyc2 etc. Apenas a saída de um deles vai para a 
tela em dado momento e há apenas um teclado para usar para entrada no console que estiver 
ativo. Logicamente, o teclado é subserviente ao console, mas isso é manifestado apenas de 
duas maneiras relativamente secundárias. Primeiramente, tty table contém uma estrutura tty 
para o console e onde são fornecidos campos separados para entrada e saída, por exemplo, 
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os campos tty devread e tty devwrite, os ponteiros para funções em keyboard.c e console.c 
são atribuídos no momento da inicialização. Entretanto, existe apenas um campo tty priv e 
isso aponta apenas para as estruturas de dados do console. Segundo, antes de entrar em seu 
laço principal, tty task chama cada dispositivo lógico uma vez, para inicializá-lo. A rotina 
chamada para /dev/console está em console.c e o código de inicialização do teclado é chama- 
do a partir de lá. Contudo, a hierarquia implícita também poderia ter sido invertida. Sempre 
vimos a entrada antes da saída ao tratar com dispositivos de E/S e continuaremos com esse 
padrão, discutindo keyboard.c nesta seção e deixando a discussão de console.c para a seção 
seguinte. 

Keyboard.c começa, assim como a maioria dos arquivos-fonte que vimos, com várias 
diretivas tinclude. Entretanto, uma delas é incomum. O arquivo keymaps/us-std.src (incluído 
na linha 15218) não é um cabeçalho normal; trata-se de um arquivo-fonte em C que resulta na 
compilação dos mapas de teclado padrão dentro de keyboard.o como um array inicializado. 
O arquivo-fonte de mapas de teclado não está incluído no Apêndice B por causa de seu tama- 
nho, mas algumas entradas representativas estão ilustradas na Figura 3-37. Após as diretibas 
Hinclude existem macros para definir várias constantes. O primeiro grupo é usado na intera- 
ção de baixo nível com a controladora do teclado. Muitas delas são endereços de porta de E/S 
ou combinações de bits que têm significado nessas interações. O grupo seguinte inclui nomes 
simbólicos para teclas especiais. Na linha 15249, o tamanho do buffer circular de entrada de 
teclado é definido simbolicamente como KB IN BYTES, com o valor 32, e o próprio buffer 
e as variáveis para gerenciá-lo são definidos em seguida. Como existe apenas um desses bu- 
ffers, deve-se tomar o cuidado de garantir que todo seu conteúdo seja processado antes que os 
consoles virtuais sejam alterados. 

As variáveis do grupo seguinte são usadas para conter vários estados que devem ser 
lembrados para a interpretação correta de um pressionamento de tecla. Elas são usadas de 
diferentes maneiras. Por exemplo, o valor do flag caps down (linha 15266) alterna entre 
TRUE e FALSE cada vez que a tecla Caps Lock é pressionada. O flag shift (linha 15264) é 
configurado como TRUE quando uma das teclas Shift é pressionada e como FALSE quando as 
duas teclas Shift são liberadas. A variável esc é configurada quando é recebido um escape de 
código de varredura. Ela é sempre reconfigurada na recepção do próximo caractere. 

Map key0 (linha 15297) é definida como uma macro. Ela retorna o código ASCII cor- 
respondente a um código de varredura, ignorando modificadores. Isso é equivalente à pri- 
meira coluna (sem Shift) no array de mapas de teclado. Sua grande irmã é map key (linha 
15303), que realiza o mapeamento completo de um código de varredura em um código AS- 
CII, incluindo o cômputo das (várias) teclas modificadoras que são pressionadas ao mesmo 
tempo que as teclas normais. 

A rotina de serviço de interrupção de teclado é kbd interrupt (linha 15335), chamada 
quando uma tecla é pressionada ou liberada. Ela chama scode para obter o código de var- 
redura dado pela controladora de teclado. O bit mais significativo do código de varredura é 
ativado quando a liberação de uma tecla causa a interrupção; tais códigos poderiam ser igno- 
rados, a não ser que fosse uma das teclas modificadoras. Entretanto, com o objetivo de fazer 
o mínimo possível para atender uma interrupção o mais rápido possível, todos os códigos de 
varredura brutos são colocados no buffer circular e o flag tp->tty events do console corrente 
é ativado (linha 15350). Para os propósitos desta discussão, presumimos, como fizemos ante- 
riormente, que nenhuma chamada select foi feita e que kbd interrupt retorna imediatamente 
depois disso. A Figura 3-41 mostra códigos de varredura no buffer para uma linha de entrada 
curta que contém dois caracteres maiúsculos, cada um precedido pelo código de varredura do 
pressionamento de uma tecla Shift e seguido pelo código da liberação da tecla Shift. Inicial- 
mente, são armazenados os códigos dos pressionamentos e das liberações de tecla. 
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Quando uma mensagem HARD INT do teclado é recebida por tty task, não é execu- 
tado o laço principal completo. O comando continue na linha 13795 faz uma nova iteração 
do laço principal iniciar imediatamente, na linha 13764. (Isso está ligeiramente simplificado; 
deixamos algum código condicional na listagem para mostrar que, se o driver de linha serial 
estiver ativado, sua rotina de tratamento de interrupção em espaço de usuário também poderá 
ser chamada.) Quando a execução é transferida para o início do laço, o flag tp->tty events do 
dispositivo de console agora é encontrado ativado e kb read (linha 15360), a rotina específica 
do dispositivo, é chamada usando o ponteiro no campo tp->tty devread da estrutura tty do 
console. 


42 | 35 | 163 | 170 | 18 | 146 | 38 | 166 | 38 | 166 | 24 | 152 | 57 | 185 
L+ | h+ h- L- e+ | e- l+ l- l+ l- o+ | o- | SP+ | SP- 


54 17 145 | 182 | 24 152 19 147 | 38 166 | 32 160 | 28 156 
R+ | w+ Ww- R- O+ O- r+ r- l+ l- d+ d- | CR+ | CR- 


Figura 3-41 Códigos de varredura no buffer de entrada, com as ações de tecla correspon- 
dentes abaixo, para uma linha de texto digitada no teclado. L e R representam as teclas Shift 
da direita e da esquerda. + e — indicam um pressionamento e uma liberação de tecla. O código 
para uma liberação é 128 a mais do que o código para um pressionamento da mesma tecla. 


Kb_read recupera os códigos de varredura do buffer circular do teclado e coloca códi- 
gos ASCII em seu buffer local, que é grande o suficiente para conter as seqüências de escape 
que devem ser geradas em resposta a alguns códigos de varredura do teclado numérico. Em 
seguida, ela chama in process no código independente de hardware para colocar os caracte- 
res na fila de entrada. Na linha 15379, icount é decrementada. A chamada para make break 
retorna o código ASCII como um valor inteiro. As teclas especiais, como as do teclado nu- 
mérico e as teclas de função, têm valores maiores do que 0xFF nesse ponto. Os códigos no 
intervalo de HOME a INSRT (0x101 a 0x10C, definido no arquivo include/minix/keymaps.h) 
resultam do pressionamento do teclado numérico e são convertidos nas segiiências de escape 
de 3 caracteres mostradas na Figura 3-42, usando o array numpad map. 

Então, as sequências são passadas para in process (linhas 15392 a 15397). Os códigos mais 
altos não são passados para in process. Em vez disso, é feita uma verificação para os códigos de 
ALT-SETA PARA A ESQUERDA, ALT-SETA PARA A DIREITA e de ALT-F1 a ALT-FI2, e 
se um deles for encontrado, select console será chamada para trocar os consoles virtuais. Seme- 
lhantemente, de CTRL-F1 a CTRL-F12 recebem tratamento especial. CTRL-F1 mostra os ma- 
peamentos das teclas de função (mais informações sobre isso posteriormente). CTRL-F3 alterna 
entre rolagem por hardware e rolagem por software da tela do console. CTRL-F7, CTRL-F8 e 
CTRL-F9 geram sinais com os mesmos efeitos de CTRL, CTRL-C e CTRL-U respectivamen- 
te, exceto que não podem ser alteradas pelo comando stty. 

Make break (linha 15431) converte códigos de varredura em ASCII e depois atualiza 
as variáveis que monitoram o estado das teclas modificadoras. Primeiramente, entretanto, ela 
verifica a combinação mágica CTRL-ALT-DEL que todos os usuários de PC conhecem como 
a maneira de forçar uma reinicialização no MS-DOS. Observe o comentário de que seria me- 
lhor fazer isso em um nível mais baixo. Entretanto, a simplicidade do tratamento de interrup- 
ção do MINIX 3 em espaço de núcleo torna a detecção de CTRL-ALT-DEL impossível ali; 
quando uma notificação de interrupção é enviada, o código de varredura ainda não foi lido. 

Uma parada de sistema de forma ordenada é desejável; portanto, em vez de tentar ini- 
ciar as rotinas da BIOS do PC, é feita uma chamada de núcleo sys kill para iniciar o envio de 
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Tecla Código de varredura | “ASCII” | Seqiiência de escape 
Home 71 0x101 ESC[H 
Seta para cima 72 0x103 ESC [A 
Pg Up 73 0x107 ESC [V 
- 74 0x10A ESC[S 
Seta para a esquerda | 75 0x105 ESC [D 
5 76 0x109 ESC [G 
Seta para a direita 77 0x106 ESC[C 
+ 78 0x10B ESC[T 
End 79 0x102 ESC [Y 
Seta para baixo 80 0x104 ESC [B 
Pg Dn 81 0x108 ESC[U 
Ins 82 0x10C ESC[ O 


Figura 3-42 Códigos de escape gerados pelo teclado numérico. Enquanto os códigos de 
varredura de teclas normais são transformados em códigos ASCII, as teclas especiais rece- 
bem códigos “pseudo-ASCII”, com valores maiores do que 0xFF. 


um sinal SIGKILL para init, o processo pai de todos os outros processos (linha 15448). Init 
deve capturar esse sinal e interpretá-lo como um comando para iniciar um procedimento de 
desligamento ordenado, antes de causar um retorno para o monitor de inicialização, a partir 
do qual uma reinicialização completa do sistema, ou uma reinicialização do MINIX 3, pode 
ser comandada. 

Naturalmente, não é realista esperar que isso funcione sempre. A maioria dos usuá- 
rios entende os perigos de um desligamento abrupto e não pressiona CTRL-ALT-DEL até 
que algo esteja dando realmente errado e o controle normal do sistema tenha se tornado 
impossível. Nesse ponto, é provável que o sistema possa estar tão instável que a sinalização 
para outro processo pode ser impossível. É por isso que há uma variável static CAD. count 
em make break. A maioria das falhas de sistema deixa o sistema de interrupção ainda em 
funcionamento; portanto, a entrada do teclado ainda pode ser recebida e o driver de terminal 
permanecerá ativo. Aqui, o MINIX 3 tira proveito do comportamento esperado dos usuários 
de computador, que tendem a pressionar teclas repetidamente quando algo parece não fun- 
cionar corretamente (possivelmente, uma evidência de que nossos ancestrais eram realmente 
macacos). Se a tentativa de eliminar init falha e o usuário pressiona CTRL-ALT-DEL mais 
duas vezes, é feita uma chamada de núcleo sys abort, causando um retorno para o monitor 
sem passar pela chamada de init. 

A parte principal de make break não é difícil de acompanhar. A variável make registra 
se o código de varredura foi gerado por um pressionamento ou por uma liberação de tecla e, 
então, a chamada para map key retorna o código ASCII para ch. Em seguida, vem um co- 
mando switch baseado no valor de ch (linhas 15460 a 15499). Vamos considerar dois casos, 
uma tecla normal e uma tecla especial. Para uma tecla normal, não há correspondência em 
nenhum dos casos e, no caso padrão (linha 15498), o código da tecla é retornado se make 
for verdadeira. Se, de algum modo, o código de uma tecla normal for aceito na liberação da 
tecla, um valor igual a -1 será substituído aqui, e isso será ignorado pela função que fez a 
chamada, kb read. Uma tecla especial, por exemplo CTRL, é identificada no lugar apropriado 
do switch, neste caso, na linha 15461. A variável correspondente, neste caso, ctrl, registra o 
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estado de make, e -1 é substituído pelo código de caractere a ser retornado (e ignorado). O 
tratamento das teclas ALT, CALOCK, NLOCK e SLOCK é mais complicado, mas para todas 
essas teclas especiais, o efeito é semelhante: uma variável registra o estado corrente (para 
teclas que só têm efeito enquanto estão pressionadas) ou alterna o estado anterior (para as 
teclas de bloqueio). 

Há mais um caso a considerar, o do código EXTKEY e a variável esc. Isso não deve ser 
confundido com a tecla ESC no teclado, que retorna o código ASCII 0x1B. Não há como 
gerar o código EXTKEY sozinho, pressionando uma tecla ou uma combinação de teclas; ele 
é o prefixo de tecla estendida do teclado do PC, o primeiro byte de um código de varredura 
de dois bytes que significa que foi pressionada uma tecla que não fazia parte do complemen- 
to de teclas original do PC, mas que tem o mesmo código de varredura. Em muitos casos, 
o software trata as duas teclas de modo idêntico. Por exemplo, isso quase sempre acontece 
com a tecla “/” normal e com a tecla “/” do teclado numérico. Em outros casos, pode-se 
querer distinguir essas teclas. Por exemplo, muitos layouts de teclado de idiomas que não 
o inglês tratam das teclas ALT da esquerda e da direita de formas diferentes para suportar 
teclas que precisam gerar três códigos de caractere diferentes. As duas teclas ALT geram o 
mesmo código de varredura (56), mas o código EXTKEY precede isso quando a tecla ALT 
da direita é pressionada. Quando o código EXTKEY é retornado, o flag esc é ativado. Neste 
caso, make break retorna de dentro do switch, pulando assim a última etapa antes de um 
retorno normal, o que configura esc como zero em qualquer outro caso (linha 15458). Isso 
tem o efeito de tornar o esc efetivo somente para o próximo código recebido. Se você estiver 
familiarizado com as complexidades do teclado do PC conforme é utilizado normalmente, 
isso será tanto conhecido como um pouco estranho, pois a BIOS do PC não permite ler o 
código de varredura de uma tecla ALT e retornar um valor diferente para o código estendido, 
como faz o MINIX 3. 

Set leds (linha 15508) liga e desliga as luzes que indicam se as teclas Num Lock, 
Caps Lock ou Scroll Lock no teclado de um PC foram pressionadas. Um byte de controle, 
LED CODE, é enviado para uma porta de saída dizendo ao teclado que o próximo byte 
escrito nessa porta é para o controle das luzes e que o status das três luzes é codificado em 
3 bits desse próximo byte. Naturalmente, essas operações são executadas por chamadas de 
núcleo que pedem para que a tarefa de sistema escreva nas portas de saída. As duas funções 
seguintes suportam essa operação. Kb wait (linha 15530) é chamada para determinar se 
o teclado está pronto para receber uma sequência de comandos e kb ack (linha 15552) é 
chamada para verificar se o comando foi reconhecido. Esses dois comandos utilizam espera 
ativa, lendo continuamente até que seja visto um código desejado. Essa não é uma técnica 
recomendada para tratar da maioria das operações de E/S, mas ligar e desligar luzes no 
teclado não vai ser feito com muita fregiiência e fazer isso de modo ineficiente não des- 
perdiça muito tempo. Note também que tanto kb wait como kb ack poderiam falhar e que 
é possível determinar, a partir do código de retorno, se isso aconteceu. Os tempos limites 
são manipulados restringindo-se o número de novas tentativas por meio de um contador no 
laço. Mas ligar a luz no teclado não é importante o bastante para merecer a verificação do 
valor retornado por uma dessas chamadas e set leds apenas prossegue cegamente. 

Como o teclado faz parte do console, sua rotina de inicialização, kb init (linha 15572), é 
chamada a partir de scr init em console.c e não diretamente a partir de tty init em tty.c. Se os 
consoles virtuais estiverem ativados (isto é, NR CONS em include/minix/config.h é maior do 
que 1), kb init é chamada uma vez para cada console lógico. A próxima função, kb init once 
(linha 15583), é chamada apenas uma vez, conforme seu nome implica (once—uma vez). Ela 
liga as luzes no teclado e varre o teclado para certificar-se de que nenhum pressionamento de 
tecla restante seja lido. Em seguida, ela inicializa dois arrays, fkey obs e sfkey obs, que são 
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usados para vincular teclas de função aos processos que devem responder a elas. Quando tudo 
está pronto, ela faz duas chamadas de núcleo, sys irqsetpolicy e sys irgenable, para configu- 
rar o IRQ do teclado e configurá-lo como automaticamente reativado, para que uma mensa- 
gem de notificação seja enviada para tty task quando uma tecla for pressionada ou liberada. 

Embora, em breve, iremos ter mais oportunidades de discutir como as teclas de função 
funcionam, este é um bom lugar para descrevermos os arrays fkey obs e sfkey obs. Cada um 
deles tem 12 elementos, pois os teclados de PC modernos têm 12 teclas de função. O primeiro 
array serve para teclas de função não modificadas; o segundo é usado quando é detectada uma 
tecla de função com Shift. Eles são compostos de elementos de tipo obs t, que é uma estru- 
tura que pode conter um número de processo e um valor inteiro. Essa estrutura e esses arrays 
são declarados em keyboard.c, nas linhas 15279 a 15281. A inicialização armazena um valor 
especial (representado simbolicamente como NONE) no componente proc nr da estrutura, 
para indicar que ele não está sendo usado. NONE é um valor fora do intervalo de números de 
processo válidos. Note que o número do processo não é um pid; ele identifica uma entrada na 
tabela de processos. Essa terminologia pode ser confusa. Mas, para enviar uma notificação, 
é usado um número de processo e não um pid, pois os números de processo são usados para 
indexar a tabela priv que determina se um processo pode receber notificações. O valor inteiro 
events também é inicialmente configurado como zero. Ele será usado para contar eventos. 

As próximas três funções são todas muito simples. Kbd loadmap (linha 15610) é qua- 
se trivial. Ela é chamada por do ioctl em tty.c para fazer a cópia de um mapa de teclado do 
espaço de usuário, para sobrescrever o mapa de teclado padrão. O padrão é compilado pela 
inclusão de um arquivo-fonte de mapa de teclado no início de keyboard.c. 

Desde sua primeira versão, o MINIX provê diferentes tipos de dumps de informações 
de sistema ou outras ações especiais, em resposta ao pressionamento das teclas de função F1, 
F2 etc., no console do sistema. Esse serviço geralmente não é fornecido em outros sistemas 
operacionais, mas o MINIX sempre teve como objetivo ser uma ferramenta de ensino. Os 
usuários são estimulados a mexer com ele, o que significa que talvez precisem de ajuda extra 
para depuração. Em muitos casos, a saída produzida pelo pressionamento de uma das teclas 
de função estará disponível mesmo quando o sistema tiver falhado. A Figura 3-43 resume 
essas teclas e seus efeitos. 

Essas teclas caem em duas categorias. Conforme mencionado anteriormente, as combi- 
nações de teclas CTRL-Fl a CTRL-F12 são detectadas por kb read. Elas disparam eventos 
que podem ser manipulados pelo driver de terminal. Esses eventos não são necessariamente 
dumps na tela. Na verdade, atualmente apenas CTRL-F1 fornece uma tela de informações; ela 
lista as correspondências das teclas de função. CTRL-F3 alterna entre rolagem por software 
e por hardware da tela do console e as outras causam o envio de sinais. 

As teclas de função pressionadas sozinhas ou junto com a tecla Shift são usadas para 
disparar eventos que não podem ser manipulados pelo driver de terminal. Elas podem resultar 
em mensagens de notificação para um servidor ou driver. Como os servidores e drivers podem 
ser carregados, ativados e desativados após o MINIX 3 já estar em execução, a associação 
estática no momento da compilação dessas teclas a essas funções não é satisfatória. Para per- 
mitir alterações em tempo de execução, tty task aceita mensagens de tipo FKEY CONTROL. 
Do fkey ctl (linha 15624) atende tais requisições. Os tipos de requisição são FKEY MAP, 
FKEY UNMAP ou FKEY EVENTS. Os dois primeiros registram ou anulam o registro de um 
processo com uma tecla especificada em um mapa de bits na mensagem e o terceiro tipo de 
mensagem retorna um mapa de bits das teclas que foram pressionadas pertencentes ao pro- 
cesso que fez a chamada e reconfigura o campo events dessas teclas. Um processo servidor, o 
servidor de informações (Information Server — IS) inicializa as configurações dos processos 
na imagem de inicialização e também serve como intermediário na geração de respostas. Mas 
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Tecla Objetivo 

Fi Tabela de processos do núcleo 

F2 Mapas de memória de processo 

F3 Imagem de inicialização 

F4 Privilégios do processo 

F5 Parâmetros do monitor de inicialização 

F6 Ganchos de IRQ e políticas 

F7 Mensagens do núcleo 

F10 Parâmetros do núcleo 

F11 Detalhes do temporização (se estiver ativado) 
F12 Filas de escalonamento 

SF1 Tabela de processos do gerenciador de processos 
SF2 Sinais 

SF3 Tabela de processos do sistema de arquivos 

SF4 Mapeamento de dispositivo/driver 

SF5 Mapeamentos de tecla de impressão 

SF9 Estatísticas de Ethernet (somente para RTL8139) 
CF1 Exibe mapeamentos de tecla 

CF3 Alterna rolagem de console por software/hardware 
CF7 Envia SIGQUIT, mesmo efeito que CTRL 

CF8 Envia SIGINT, mesmo efeito que CTRL-C 

CF9 Envia SIGKILL, mesmo efeito que CTRL-U 


Figura 3-43 As teclas de função detectadas por func_key(). 


drivers individuais também podem ser registrados para responder a uma tecla de função. Os 
drivers Ethernet fazem isso normalmente, pois um dump mostrando as estatísticas sobre pa- 
cotes pode ser útil na solução de problemas de rede. 

Func_key (linha 15715) é chamada a partir de kb_read para verificar se foi pressionada 
uma tecla especial destinada a processamento local. Isso é feito para cada código de varre- 
dura recebido, antes de qualquer outro processamento. Se não for uma tecla de função, no 
máximo três comparações são feitas antes que o controle seja retornado para kb_read. Se uma 
tecla de função é registrada, uma mensagem de notificação é enviada para o processo apro- 
priado. Se esse processo registrou apenas uma tecla, a notificação sozinha é suficiente para o 
processo saber o que fazer. Se um processo é o servidor de informações ou outro que tenha 
registrado várias teclas, é exigido um diálogo — o processo deve enviar uma requisição de 
FKEY_EVENTS para o driver de terminal, para ser processada por do_fkey_ctl, que informará 
o processo que fez a chamada sobre quais teclas estavam ativas. O processo que fez a chama- 
da pode, então, despachar para a rotina de cada tecla que foi pressionada. 

Scan_keyboard (linha 15800) trabalha no nível da interface de hardware, lendo e en- 
viando bytes em portas de E/S. A controladora de teclado é informada de que um caractere foi 
lido pela sequência nas linhas 15809 e 15810, a qual lê um byte e o escreve novamente com o 
bit mais significativo configurado como 1 e, então, o reescreve com o mesmo bit reconfigura- 
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3.8.6 


do como 0. Isso impede que os mesmos dados sejam lidos em uma leitura subseqiiente. Não 
há verificação de status na leitura do teclado, mas não deverá haver problema de qualquer 
modo, pois scan keyboard só é chamada em resposta a uma interrupção. 

A última função em keyboard.c é do panic dumps (linha 15819). Se for ativada como 
resultado de uma situação de pânico no sistema, ela proporciona uma oportunidade para o 
usuário utilizar as teclas de função para exibir informações de depuração. O laço nas linhas 
15830 a 15854 é outro exemplo de espera ativa. O teclado é lido repetidamente até que a tecla 
ESC seja pressionada. Certamente, ninguém pode dizer que uma técnica mais eficiente é ne- 
cessária após uma falha, enquanto se espera um comando para reinicializar. Dentro do laço, 
a operação de recepção sem bloqueio raramente usada, nb receive, é utilizada para permitir 
mensagens de aceite alternativas, se estiverem disponíveis, e testar a existência de entrada no 
teclado, que pode ser uma das opções sugeridas na mensagem 


Hit ESC to reboot, DEL to shutdown, F-keys for debug dumps 


impressa ao se entrar nessa função. Na próxima seção, veremos o código que implementa 
do newkmess e do diagnostics. 


Implementação do driver de vídeo 


O vídeo do IBM PC pode ser configurado como vários terminais virtuais, caso haja memória 
suficiente disponível. Nesta seção, examinaremos o código dependente de dispositivo do con- 
sole. Veremos também as rotinas de dump de depuração que utilizam serviços de mais baixo 
nível do teclado e do vídeo. Elas fornecem uma interação limitada com o usuário que está 
diante do console, mesmo quando outras partes do sistema MINIX 3 não estão funcionando, 
e podem fornecer informações úteis, mesmo após uma falha quase total do sistema. 

O suporte específico do hardware para saída de console para a tela mapeada em memó- 
ria do PC está em console.c. A estrutura console está definida nas linhas 15981 a 15998. De 
certa forma, essa estrutura é uma extensão da estrutura tty definida em tty.c. Na inicialização, 
o campo tp->tty priv da estrutura tty de um console recebe um ponteiro para sua própria es- 
trutura console. O primeiro item na estrutura console é um ponteiro de volta para a estrutura 
tty correspondente. Os campos de uma estrutura console são os que se esperaria para um 
monitor de vídeo: variáveis para registrar linha e coluna da posição do cursor, os endereços 
de memória do início e do limite de memória usado para a tela, o endereço de memória 
apontado pelo ponteiro de base da controladora e o endereço corrente do cursor. Outras va- 
riáveis são usadas para gerenciar sequências de escape. Como os caracteres são inicialmente 
recebidos como bytes (8 bits) e devem ser combinados com bytes de atributo e transferidos 
como palavras de 16 bits para a memória de vídeo, é feito um bloco para ser transferido em 
c ramqueue. Esse bloco é um array grande o suficiente para conter uma linha inteira de 80 
colunas de pares de atributos de caracteres de 16 bits. Cada console virtual precisa de uma 
estrutura console e o armazenamento é alocado no array cons. table (linha 16001). Assim 
como fizemos com a estrutura tty e com outras estruturas, normalmente vamos nos referir aos 
elementos de uma estrutura console usando um ponteiro; por exemplo, cons->c tty. 

A função cujo endereço é armazenado na entrada tp->tty devwrite de cada console é 
cons. write (linha 16036). Ela é chamada a partir de um lugar apenas, handle events em tty.c. 
A maior parte das outras funções em console.c existe para suportar essa função. Quando ela 
é chamada pela primeira vez, após um processo cliente fazer uma chamada write, os dados a 
serem gerados na saída estão no buffer do cliente, que pode ser encontrado usando-se os cam- 
pos tp->tty outproc e tp->out vir na estrutura tty. O campo tp->tty outleft informa quantos 
caracteres devem ser transferidos e o campo tp->tty outcum é inicialmente zero, indicando 
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que nada ainda foi transferido. Essa é a situação normal ao se entrar em cons. write, pois, nor- 
malmente, quando chamada, a função transfere todos os dados solicitados na chamada origi- 
nal. Entretanto, se o usuário quiser diminuir a velocidade do processo para examinar os dados 
na tela, ele pode digitar um caractere STOP (CTRL-S) no teclado, resultando na ativação do 
flag tp->tty inhibited. Cons. write retorna imediatamente quando esse flag é ativado, mesmo 
que a operação write não tenha terminado. Nesse caso, handle events continuará a chamar 
cons write e, quando tp->tty inhibited for finalmente desativado, pelo usuário digitando um 
caractere START (CTRL-Q), cons write continuará com a transferência interrompida. 

O primeiro argumento de cons write é um ponteiro para a estrutura tty de um console 
em particular; portanto, a primeira coisa que deve ser feita é inicializar cons, o ponteiro para a 
estrutura console desse console (linha 16049). Então, como handle events chama cons write 
ao ser executada, a primeira ação é um teste para ver se há realmente trabalho a ser feito. Se 
não houver, é feito um rápido retorno (linha 16056). Depois disso, entra-se no laço princi- 
pal, nas linhas 16061 a 16089. Esse laço é estruturalmente semelhante ao laço principal de 
in transfer em tty.c. Um buffer local, que pode conter 64 caracteres, é preenchido pelo uso 
da chamada de núcleo sys vircopy para obter os dados do buffer do cliente. Depois disso, o 
ponteiro para a origem e as contabilizações são atualizados e, então, cada caractere no buffer 
local é transferido para o array cons->c ramqueue, junto com um byte de atributo, para 
transferência posterior para a tela, feita por flush. 

A transferência de caracteres de cons->c ramqueue pode ser feita de mais de uma ma- 
neira, conforme vimos na Figura 3-35. Out char pode ser chamada para fazer isso para cada 
caractere, mas é possível que nenhum dos serviços especiais de out char seja necessário, 
caso que o caractere seja um caractere visível, que uma seqiiência de escape não esteja em 
andamento, que a largura da tela não tenha sido ultrapassada e que cons->c ramqueue não 
esteja completa. Se o serviço completo de out char não é necessário, o caractere é coloca- 
do diretamente em cons->c ramqueue, junto com o byte de atributo (que é recuperado de 
cons->c. attr), e cons->c. rwords (que é o índice para a fila), cons->c. column (que monitora 
a coluna na tela) e tbuf, o ponteiro para o buffer, são todos incrementados. Essa colocação 
direta de caracteres em cons->c ramqueue corresponde à linha tracejada no lado esquerdo da 
Figura 3- 35. Se necessário, out char é chamada (linha 16082). Ela faz toda a contabilização 
e, além disso, chama flush, que realiza a transferência final para a memória da tela, quando 
necessário. 

A transferência do buffer de usuário para o buffer local e para a fila é repetida, con- 
tanto que tp->tty outleft indique que ainda existem caracteres a serem transferidos e o flag 
tp->tty inhibited não tenha sido ativado. Quando a transferência pára, seja porque a opera- 
ção write terminou, seja porque tp->tty inhibited foi ativado, flush é chamada novamente 
para transferir os últimos caracteres da fila para a memória da tela. Se a operação tiver 
terminado (o que é testado vendo-se se tp->tty outleft é zero), uma mensagem de resposta 
será enviada pela chamada de tty reply, nas linhas 16096 e 16097). 

Além das chamadas para cons write feitas por handle events, os caracteres a serem 
exibidos também são enviados para o console por echo e rawecho na parte independente de 
hardware do driver de terminal. Se o console é o dispositivo de saída corrente, as chamadas 
feitas por meio do ponteiro tp->tty echo são dirigidas para a próxima função, cons echo 
(linha 16105). Cons echo faz todo o seu trabalho chamando out char e, em seguida, flush. 
A entrada do teclado chega caractere por caractere e a pessoa que está digitando deseja ver 
o eco sem nenhum atraso perceptível; portanto, colocar os caracteres na fila de saída seria 
insatisfatório. 

Out char (linha 16119) faz um teste para ver se uma seqiiência de escape está em anda- 
mento, chamando parse escape e depois retornando imediatamente, se estiver (linhas 16124 
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a 16126). Caso contrário, executa-se um comando switch para verificar os casos especiais: 
caractere nulo, de retrocesso, sinal sonoro etc. O tratamento da maioria deles é fácil de acom- 
panhar. O avanço de linha e a tabulação são os mais complicados, pois envolvem mudanças 
complicadas na posição do cursor na tela e também podem exigir rolagem. O último teste é 
para o código ESC. Se ele for encontrado, o flag cons->c esc state será ativado (linha 16181) 
e as futuras chamadas para out char serão desviadas para parse escape até que a sequência 
esteja completa. No final, o padrão é adotado para caracteres imprimíveis. Se a largura da 
tela tiver sido ultrapassada, talvez a tela precise ser rolada, e flush é chamada. Antes que um 
caractere seja colocado na fila de saída é feito um teste para ver se a fila não está cheia e, caso 
esteja, flush é acionada. Colocar um caractere na fila exige a mesma contabilização que vimos 
anteriormente em cons. write. 

A próxima função é scroll screen (linha 16205). Scroll screen manipula tanto a rola- 
gem para cima, a situação normal que deve ser tratada quando a linha inferior da tela estiver 
cheia, quanto a rolagem para baixo, que ocorre quando os comandos de posicionamento do 
cursor tentam movê-lo para além da linha superior da tela. Para cada direção de rolagem, 
existem três métodos possíveis. Eles são exigidos para suportar diferentes tipos de placas 
de vídeo. 

Veremos o caso da rolagem para cima. Para começar, chars recebe o tamanho da tela, 
menos uma linha. A rolagem por software é feita por meio de uma única chamada para 
vid vid copy, para mover chars caracteres mais para baixo na memória, sendo a amplitude 
do movimento o número de caracteres presentes em uma linha. Vid vid copy pode fazer 
uma referência circular à memória; isto é, se solicitada a mover um bloco de memória que 
ultrapasse a extremidade superior do bloco atribuído ao monitor de vídeo, ela busca a parte 
que transbordou da extremidade inferior do bloco de memória e a coloca em um endereço 
mais alto do que a parte movida para baixo, tratando o bloco inteiro como um array circular. 
A simplicidade da chamada oculta uma operação bastante lenta, mesmo sendo vid vid copy 
uma rotina em linguagem assembly (definida em drivers/tty/vidcopy.s e não listada no Apên- 
dice B). Essa chamada exige que a CPU mova 3840 bytes, o que é trabalhoso, mesmo em 
linguagem assembly. 

O método de rolagem por software nunca é o padrão; o operador só deve selecioná-lo 
se a rolagem por hardware não funcionar ou não for desejada por alguma razão. Um motivo 
poderia ser o desejo de usar o comando screendump, seja para salvar a memória da tela em 
um arquivo, seja para ver a tela do console principal ao trabalhar em um terminal remoto. 
Quando a rolagem por hardware estiver vigorando, é provável que screendump forneça re- 
sultados inesperados, pois o início da memória da tela provavelmente não coincidirá com o 
início da tela visível. 

Na linha 16226, a variável wrap é testada como a primeira parte de um teste composto. 
Wrap é verdadeira para vídeos mais antigos que podem suportar rolagem por hardware e, se 
o teste falhar, a rolagem por hardware simples ocorrerá na linha 16230, onde o ponteiro de 
origem usado pela controladora de vídeo, cons->c org, é atualizado para apontar para o pri- 
meiro caractere a ser exibido no canto superior esquerdo da tela. Se wrap for FALSE, o teste 
continuará para verificar se o bloco a ser movido para cima na operação de rolagem ultrapas- 
sa os limites do bloco de memória designado para esse console. Se assim for, vid vid copy 
será chamada novamente para fazer o movimento circular no qual o bloco vai para o início da 
memória alocada do console, e o ponteiro de origem será atualizado. Se não houver sobrepo- 
sição, o controle passará para o método de rolagem por hardware simples, sempre utilizado 
pelas controladoras de vídeo mais antigas. Isso consiste em ajustar cons->c org e depois 
colocar a nova origem no registrador correto do chip da controladora. A chamada para fazer 
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isso é executada posteriormente, assim como uma chamada para limpar a linha inferior na 
tela para obter o efeito de “rolagem”. 

O código para rolar para baixo é muito parecido com o da rolagem para cima. Final- 
mente, mem vid copy é chamada para limpar a linha inferior (ou superior) endereçada por 
new line. Então, set 6845 é chamada para escrever a nova origem de cons->c. org nos regis- 
tradores apropriados e flush garante que todas as alterações se tornem visíveis na tela. 

Mencionamos flush (linha 16259) várias vezes. Ela transfere os caracteres que estão 
na fila para a memória de vídeo usando mem vid copy, atualiza algumas variáveis e, em 
seguida, garante que os números de linha e coluna sejam razoáveis, ajustando-os se, por 
exemplo, uma sequência de escape tiver tentado mover o cursor para uma posição de coluna 
negativa. Finalmente, é feito um cálculo de onde o cursor deveria estar e é comparado com 
cons->c cur. Se eles não coincidirem e se a memória de vídeo correntemente manipulada 
pertencer ao console virtual corrente, será feita uma chamada para set 6845 para configurar 
o valor correto no registrador de cursor da controladora. 

A Figura 3-44 mostra como o tratamento da seqiiência de escape pode ser representado 
com uma máquina de estado finito. Isso é implementado por parse escape (linha 16293), que é 
chamada no início de out char se cons->c esc state não for zero. Um ESC em si é detectado 
por out char e torna cons->c esc state igual a 1. Quando o próximo caractere é recebido, 
parse escape se prepara para mais processamento colocando “A0” em cons->c esc intro, um 
ponteiro para o início do array de parâmetros, cons->c esc parmv[0] em cons->c esc parmp, 
e zeros no array de parâmetros em si. Então, o primeiro caractere imediatamente após o ESC 
é examinado—os valores válidos são “[” ou “M”. No primeiro caso, o “[” é copiado em cons- 
>c esc intro e o estado avança para 2. No segundo caso, do escape é chamada para executar 
a ação e o estado do escape é reconfigurado com zero. Se o primeiro caractere após o ESC não 
for um dos que são válidos, ele será ignorado e os caracteres seguintes serão novamente exibi- 
dos da forma normal. 


c esc siate= 1 ago numérico 


ou “” 
Não “P 


chama 
do escape 


Não ESC 


chama Não 
do escape numérico ou “” 


coleta 
parâmetros 
numéricos 


Figura 3-44 Máquina de estado finito para processamento de segiiências de escape. 


Quando é encontrada uma sequência ESC [, o próximo caractere inserido é processado 
pelo código de estado de escape 2. Nesse ponto, existem três possibilidades. Se o caractere 
for numérico, seu valor será extraído e adicionado a 10 vezes o valor existente na posição 
correntemente apontada por cons->c esc parmp, inicialmente cons->c esc parmvl[0] (que 
foi inicializado com zero). O estado de escape não muda. Isso torna possível inserir uma sé- 
rie de dígitos decimais e acumular um parâmetro numérico grande, embora o valor máximo 
correntemente reconhecido pelo MINIX 3 seja 80, usado pela segiiência que move o cursor 
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para uma posição arbitrária (linhas 16335 a 16337). Se o caractere for um ponto-e-vírgula, 
haverá outro parâmetro; portanto, o ponteiro para a string de parâmetros avança, permitindo 
que sucessivos valores numéricos sejam acumulados no segundo parâmetro (linhas 16339 a 
16341). Se fosse necessário modificar MAX ESC PARMS para alocar um array maior para 
os parâmetros, esse código não precisaria ser alterado para acumular valores numéricos adi- 
cionais, após a entrada de parâmetros adicionais. Finalmente, se o caractere não for um dígito 
numérico nem um ponto-e-vírgula, do escape será chamada. 

Do escape (linha 16352) é uma das funções mais longas no código-fonte do sistema 
MINIX 3, mesmo sendo o complemento de seqiiências de escape reconhecidas do MINIX 3 
relativamente modesto. Entretanto, apesar de seu tamanho, o código deve ser fácil de seguir. 
Após uma chamada inicial para flush, para garantir que o monitor de vídeo seja comple- 
tamente atualizado, através de um simples if, é feito uma tomada de decisão dependendo 
de o caractere imediatamente após o caractere ESC ter sido um introdutor de sequência de 
controle especial ou não. Se não foi, há apenas uma ação válida: mover o cursor uma linha 
para cima, caso a sequência tenha sido ESC M. Note que o teste do “M” é feito dentro de um 
switch na clausula default, como uma verificação de validade e antecipando a adição de outras 
sequências que não usam o formato ESC [. A ação é típica de muitas segiiências de escape: 
a variável cons->c row é inspecionada para determinar se é necessário rolar. Se o cursor já 
está na linha 0, é feita uma chamada de SCROLL DOWN para scroll screen; caso contrário, 
o cursor é movido uma linha para cima. Esta última ação é realizada apenas decrementando- 
se cons->c. row e, então, chamando-se flush. Se for encontrado um introdutor de sequência 
de controle, será usado o código após a instrução else na linha 16377. É feito um teste para 
“[”, o único introdutor de segiiência de controle correntemente reconhecido pelo MINIX 3. 
Se a sequência for válida, o primeiro parâmetro encontrado na sequência de escape (ou zero, 
se nenhum parâmetro numérico foi inserido) será atribuído a value (linha 16380). Se a se- 
quência for inválida, nada acontecerá, exceto que o grande switch que se segue (linhas 16381 
a 16586) será pulado e o estado de escape será reconfigurado como zero antes de retornar de 
do escape. No caso mais interessante, em que a segiiência é válida, entra-se no switch. Não 
vamos discutir todos os casos; mencionaremos apenas vários que são representativos dos 
tipos de ações governadas pelas segiiências de escape. 

As primeiras cinco segiiências são geradas, sem argumentos numéricos, pelas quatro 
teclas de seta e pela tecla Home no teclado do IBM PC. As duas primeiras, ESC [A e ESC [B, 
são semelhantes à ESC M, exceto que podem aceitar um parâmetro numérico e mover para 
cima e para baixo por mais de uma linha, e elas não rolam a tela se o parâmetro especificar 
um movimento que ultrapasse os limites da tela. Em tais casos, flush captura as requisições 
para mover fora dos limites e restringe o movimento à última ou à primeira linha, conforme 
for apropriado. As duas segiiências seguintes, ESC [C e ESC [D, que movem o cursor para 
a direita e para a esquerda, são semelhantemente limitadas por flush. Quando geradas pelas 
teclas de seta, não há nenhum argumento numérico e, assim, ocorre o movimento padrão de 
uma única linha ou coluna. 

ESC [H pode receber dois parâmetros numéricos; por exemplo, ESC [20;60H. Os pa- 
râmetros especificam uma posição absoluta (em vez de relativa) para a posição corrente 
e são convertidos de números de base 1 para números de base 0, para uma interpretação 
correta. A tecla Home gera a sequência padrão (sem parâmetros) que move o cursor para a 
posição (1, 1). 

ESC [sJ e ESC [sK limpam uma parte da tela inteira ou da linha corrente, dependendo 
do parâmetro inserido. Em cada caso, é calculada uma contagem de caracteres. Por exemplo, 
para ESC [1J, count recebe o número de caracteres desde o início da tela até a posição do cur- 
sor, e a contagem e um parâmetro de posição, dst, que pode ser o início da tela, cons->c org, 
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ou a posição corrente do cursor, cons->c. cur, são usados como parâmetros em uma chamada 
para mem vid copy. Essa função é chamada com um parâmetro que a faz preencher a região 
especificada com a cor de fundo corrente. 

As quatro sequências seguintes inserem e excluem linhas e espaços na posição do cursor, 
e suas ações não exigem explicação detalhada. O último caso, ESC [nm (observe que n repre- 
senta um parâmetro numérico, mas m é um caractere literal) tem seu efeito sobre cons->c. attr, 
o byte de atributo intercalado entre os códigos de caractere quando são escritos na memória de 
vídeo. 

A próxima função, set 6845 (linha 16594), é usada quando é necessário atualizar a con- 
troladora de vídeo. O 6845 tem registradores de 16 bits internos que são programados 8 bits 
por vez, e inicializar um único registrador exige quatro operações de escrita na porta de E/S. 
Elas são executadas pela configuração de um array (vetor) de pares (porta, valor) e por uma 
chamada de núcleo sys voutb para fazer com que a tarefa de sistema realize a E/S. Alguns 
dos registradores da controladora de vídeo 6845 aparecem na Figura 3-45 


Registradores Função 

10-11 Tamanho do cursor 

12-13 Endereço inicial para desenhar na tela 
14-15 Posição do cursor 


Figura 3-45 Alguns registradores do 6845. 


A próxima função é get_6845 (linha 16613), que retorna os valores dos registradores 
da controladora de vídeo passíveis de leitura. Ela também usa chamadas de núcleo para exe- 
cutar seu trabalho. Essa função não parece ser chamada de nenhum lugar no código corrente 
do MINIX 3, mas pode ser útil para aprimoramentos futuros, como a adição de suporte para 
imagens gráficas. 

A função beep (linha 16629) é chamada quando um caractere CTRL-G precisa ser gera- 
do na saída. Ela tira proveito do suporte interno fornecido pelo PC para emitir sons por meio 
do envio de uma onda quadrada para o alto-falante. O som é iniciado pelo tipo de manipu- 
lação mágica de portas de E/S que apenas os programadores de linguagem assembly podem 
gostar. A parte mais interessante do código é o uso da capacidade de configurar um alarme 
para desligar o bip. Como um processo com privilégios de sistema (isto é, uma entrada na ta- 
bela priv), o driver de terminal pode configurar um temporizador usando a função de bibliote- 
ca tmrs_settimers. Isso é feito na linha 16655, com a próxima função, stop beep, especificada 
como aquela a ser executada quando o temporizador expirar. Esse temporizador é colocado 
na fila de temporizadores da própria tarefa de terminal. A chamada de núcleo sys setalarm 
seguinte pede para que a tarefa de sistema configure um temporizador no núcleo. Quando ele 
expira, uma mensagem SYN ALARM é detectada pelo laço principal do driver de terminal, 
tty task, o qual chama expire timers para tratar de todos os temporizadores pertencentes ao 
driver de terminal, um dos quais é aquele configurado por beep. 

A próxima rotina, stop beep (linha 16666), é aquela cujo endereço é colocado no cam- 
po tmr func do temporizador iniciado por beep. Ela interrompe o bip depois que o tempo 
designado tiver decorrido e também desativa o flag beeping. Isso impede que chamadas su- 
pérfluas à rotina beep tenham qualquer efeito. 

Scr init (linha 16679) é chamada por tty init NR CONS vezes. A cada vez, seu argu- 
mento é um ponteiro para uma estrutura tty, um elemento de tty table. Nas linhas 16693 e 
16694, line, a ser usada como índice para o array cons. table, é calculada, sua validade é tes- 
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tada e, se for válida, é usada para inicializar cons, o ponteiro para a entrada da tabela de con- 
sole corrente. Nesse ponto, o campo cons->c tty pode ser inicializado com o ponteiro para a 
estrutura tty principal do dispositivo e, por sua vez, tp->tty priv pode apontar para a estrutura 
console t desse dispositivo. Em seguida, kb init é chamada para inicializar o teclado e, então, 
são configurados os ponteiros para rotinas específicas do dispositivo, tp->tty devwrite apon- 
tando para cons write, tp->tty echo apontando para cons echo e tp->tty ioctl apontando 
para cons. ioctl. O endereço de E/S do registrador de base da controladora do CRT é buscado 
na BIOS, o endereço e o tamanho da memória de vídeo são determinados nas linhas 16708 
a 16731 e o flag wrap (usado para determinar como será a rolagem) é configurado de acordo 
com a classe de controladora de vídeo em uso. Na linha 16735, o descritor de segmento da 
memória de vídeo é inicializado na tabela de descritores global pela tarefa de sistema. 

Em seguida, vem a inicialização de consoles virtuais. Sempre que scr init é chamada, 
o argumento é um valor diferente de tp e, assim, um valor de line e de cons diferentes são 
usados nas linhas 16750 a 16753 para fornecer a cada console virtual sua própria fatia da 
memória de vídeo disponível. Então, cada tela é limpa, fica pronta para iniciar e, finalmente, 
o console O é selecionado para ser o primeiro ativo. 

Várias rotinas exibem saída em nome do driver de terminal em si, do núcleo ou de outro 
componente do sistema. A primeira, kputc (linha 16775) apenas chama putk, uma rotina para 
produzir saída de texto um byte por vez, a ser descrita a seguir. Essa rotina está aqui porque 
a rotina de biblioteca que fornece a função printf usada dentro de componentes do sistema é 
escrita para ser ligada a uma rotina de impressão de caracteres que tem esse nome, mas outras 
funções no driver de terminal esperam uma função chamada putk. 

Do new kmess (linha 16784) é usada para imprimir mensagens do núcleo. Na verdade, 
mensagens não é a melhor palavra para usar aqui; não queremos dizer mensagens conforme 
utilizadas para comunicação entre processos. Essa função serve para exibir texto no console 
para fornecer informações, alertas ou relatos de erros para o usuário. 

O núcleo precisa de um mecanismo especial para exibir informações. Ele também pre- 
cisa ser robusto, para que possa ser usado durante a inicialização, antes que todos os com- 
ponentes do MINIX 3 estejam em funcionamento, ou durante uma situação de pânico, outro 
momento em que as principais partes do sistema podem estar indisponíveis. O núcleo es- 
creve texto em um buffer circular de caracteres, parte de uma estrutura que também contém 
ponteiros para o próximo byte a ser escrito e o tamanho do texto ainda a ser processado. O 
núcleo envia uma mensagem SYS SIG para o driver de terminal quando existe um texto 
novo e do new kmess é chamada quando o laço principal em tty task está em execução. 
Quando as coisas não transcorrerem normalmente (isto é, quando o sistema falhar), a mensa- 
gem SYS SIG será detectada pelo laço, que inclui uma operação de leitura sem bloqueio, em 
do panic dumps, que vimos em keyboard.c, e do new kmess será chamada a partir de lá. Em 
qualquer caso, a chamada de núcleo sys getkmessages recupera uma cópia da estrutura do 
núcleo e os bytes são exibidos, um por um, passando-os para putk, seguido de uma chamada 
final para putk com um byte nulo, para obrigá-la a gerar a saída. Uma variável estática local é 
usada para monitorar a posição no buffer entre as mensagens. 

Do diagnostics (linha 16823) tem uma função semelhante à de do new kmess, mas é 
usada para exibir mensagens de processos de sistema, em vez do núcleo. Uma mensagem DIAG- 
NOSTICS pode ser recebida pelo laço principal de tty task ou pelo laço em do panic dumps e, 
em qualquer caso, é feita uma chamada para do. diagnostics. A mensagem contém um pon- 
teiro para um buffer no processo que fez a chamada e uma contagem do tamanho da mensa- 
gem. Nenhum buffer local é usado; em vez disso, são feitas chamadas de núcleo sys vircopy 
repetidas para obter o texto um byte por vez. Isso protege o driver de terminal; caso algo dê 
errado e um processo começar a gerar um volume de saída excessivo, não haverá nenhum 
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buffer para inundar. Os caracteres aparecem na saída um por um, pela chamada de putk, 
seguida de um byte nulo. 

Putk (linha 16850) pode imprimir caracteres em nome de qualquer código vinculado 
ao driver de terminal e é usada pelas funções que acabamos de descrever para gerar texto na 
saída em nome do núcleo ou de outros componentes do sistema. Ela apenas chama out char 
para cada byte não-nulo recebido e, então, chama flush para o byte nulo no final da string. 

As rotinas restantes em console.c são curtas e simples, e as examinaremos rapidamente. 
Toggle scroll (linha 16869) faz o que seu nome diz: ela alterna o flag que determina se vai ser 
usada rolagem por software ou por hardware. Ela também exibe uma mensagem na posição 
corrente do cursor para identificar o modo selecionado. Cons. stop (linha 16881) reinicializa 
o console com o estado esperado pelo monitor de inicialização, antes de um desligamento ou 
de uma reinicialização. Cons org0 (linha 16893) é usada apenas quando uma mudança no 
modo de rolagem é imposta pela tecla F3 ou na preparação para desligar. Select console (li- 
nha 16917) seleciona um console virtual. Ela é chamada com o novo índice e chama set 6845 
duas vezes para fazer a controladora de vídeo exibir a parte correta da memória de vídeo. 

As duas rotinas seguintes são altamente específicas do hardware. Con loadfont (linha 
16931) carrega uma fonte em um adaptador gráfico, no suporte da operação ioctl TIOCSFON. 
Ela chama ga program (linha 16971) para realizar uma série de escritas mágicas em uma 
porta de E/S, que fazem com que a memória de fonte do adaptador de vídeo, que normalmen- 
te não pode ser endereçada pela CPU, seja visível. Então, phys. copy é chamada para copiar 
os dados da fonte nessa área da memória e outra segiiência mágica é ativada para retornar o 
adaptador gráfico ao seu modo de operação normal. 

A última função é cons. ioctl (linha 16987). Ela executa apenas uma tarefa, configurar 
o tamanho da tela, e é chamada apenas por scr. init, que utiliza valores obtidos da BIOS. Se 
houvesse necessidade de uma chamada ioctl real para alterar o tamanho da tela do MINIX 3, 
o código para fornecer as novas dimensões precisaria ser escrito. 


RESUMO 


Entrada/saída é um assunto importante, fregientemente negligenciado. Uma parte significati- 
va de qualquer sistema operacional está relacionada com a E/S. Mas os drivers de dispositivo 
de E/S muitas vezes são responsáveis por problemas do sistema operacional. Frequentemen- 
te, os drivers são escritos por programadores que trabalham para fabricantes de dispositi- 
vos. Normalmente, os projetos de sistema operacional convencionais exigem permitir que 
os drivers tenham acesso a recursos críticos, como interrupções, portas de E/S e memória 
pertencente a outros processos. O projeto do MINIX 3 isola os drivers como processos inde- 
pendentes, com privilégios limitados, de modo que um erro em um driver não pode fazer o 
sistema inteiro falhar. 

Começamos vendo o hardware de E/S e o relacionamento dos dispositivos de E/S com 
as controladoras de E/S, que são o que o software precisa tratar. Em seguida, passamos para 
os quatro níveis de software de E/S: as rotinas de interrupção, os drivers de dispositivo, o 
software de E/S independente de dispositivo e as bibliotecas de E/S e o spool executados em 
espaço de usuário. 

Então, examinamos o problema do impasse e como ele pode ser atacado. O impasse 
ocorre quando a cada processo de um grupo de processos é garantido o acesso exclusivo a 
alguns recursos e cada um quer ainda outro recurso pertencente a outro processo do grupo. 
Todos eles serão bloqueados e nenhum jamais será executado novamente. O impasse pode 
ser evitado estruturando-se o sistema de modo que ele nunca possa ocorrer; por exemplo, 
permitindo que um processo possua apenas um recurso em dado momento. Ele também pode 
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ser evitado examinando-se cada pedido de recurso para ver se ele leva a uma situação na qual 
um impasse é possível (um estado inseguro) e negando ou retardando aqueles que geram 
problemas. 

No MINIX 3, os drivers de dispositivo são implementados como processos indepen- 
dentes executando em espaço dd usuário. Vimos o driver de disco em RAM, o driver de 
disco rígido e o driver de terminal. Cada um desses drivers tem um laço principal que recebe 
requisições, as processam, e no fim envia respostas de retorno para relatar o que aconteceu. 
O código-fonte dos laços principais e das funções comuns do disco em RAM, do disco rígido 
e dos drivers de disquete é fornecido em uma biblioteca de drivers comum, mas cada driver 
é compilado e ligado com sua própria cópia das rotinas de biblioteca. Cada driver de dispo- 
sitivo é executado em seu próprio espaço de endereço. Vários terminais diferentes, usando o 
console do sistema, as linhas seriais e conexões de rede, são suportados por um único proces- 
so de driver de terminal. 

Os drivers de dispositivo possuem relacionamentos variados com o sistema de interrup- 
ção. Os dispositivos que podem concluir seu trabalho rapidamente, como o disco em RAM 
e o vídeo mapeado em memória, não utilizam interrupções. O driver de disco rígido executa 
a maior parte de seu trabalho no próprio código do driver e as rotinas de tratamento de inter- 
rupção apenas retornam informações de status. As interrupções são sempre esperadas e uma 
operação receive pode ser executada para esperar uma interrupção. Uma interrupção de tecla- 
do pode acontecer a qualquer momento. As mensagens geradas por todas as interrupções para 
o driver de terminal são recebidas e processadas no laço principal do driver. Quando ocorre 
uma interrupção de teclado, o primeiro estágio do processamento da entrada é executado o 
mais rapidamente possível, para estar pronto para as interrupções subsequentes. 

Os drivers do MINIX 3 têm privilégios limitados e não podem manipular interrupções 
nem acessar portas de E/S por conta própria. As interrupções são manipuladas pela tarefa 
de sistema, a qual envia uma mensagem para notificar um driver quando ocorre uma inter- 
rupção. Analogamente, o acesso às portas de E/S é intermediado pela tarefa de sistema. Os 
drivers não podem ler nem escrever diretamente em portas de E/S. 


PROBLEMAS 


1. Um leitor de DVD-1x pode fornecer dados a uma velocidade de 1,32 MB/s. Qual é a unidade de 
DVD de velocidade mais alta que poderia ser conectada por meio de uma conexão USB 2.0 sem 
perda de dados? 


2. Muitos discos contêm um ECC no final de cada setor. Se o ECC estiver errado, quais ações podem 
ser executadas e por qual parte do hardware ou do software? 


3. O que é E/S mapeada em memória? Por que ela é usada às vezes? 
4. Explique o que é DMA e por que ele é usado. 


5. Embora o DMA não utilize a CPU, a taxa de transferência máxima ainda é limitada. Considere a 
leitura de um bloco do disco. Cite três fatores que poderiam, em última análise, limitar a taxa de 
transferência. 


6. Uma música com qualidade de CD exige a amostragem do sinal de áudio 44.100 vezes por segun- 
do. Suponha que um temporizador gere uma interrupção a essa velocidade e que cada interrupção 
demore 1 microssegundo para ser manipulada em uma CPU de 1 GHz. Qual é a menor velocidade 
de relógio que poderia ser usada e não perder nenhum dado? Suponha que o número de instruções 
a serem processadas para uma interrupção seja constante, de modo que reduzir a velocidade do 
relógio pela metade duplica o tempo de tratamento da interrupção. 
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7. 


8. 


9. 


10. 


11. 


12. 


13. 
14. 


15. 


16. 


17. 


18. 


19. 


20. 


21. 


Uma alternativa às interrupções é o polling. Você consegue imaginar circunstâncias nas quais o 
polling é a melhor escolha? 


As controladoras de disco têm buffers internos e estão ficando maiores a cada novo modelo. Por 
quê? 


Cada driver de dispositivo tem duas interfaces diferentes com o sistema operacional. Uma interface 
é um conjunto de chamadas de função que o sistema operacional faz no driver. A outra é um con- 
Junto de chamadas que o driver faz no sistema operacional. Cite uma provável chamada em cada 
interface. 


Por que os projetistas de sistema operacional tentam fornecer E/S independente de dispositivo 
quando possível? 


Em qual das quatro camadas de software de E/S cada uma das seguintes atividades é realizada? 


(a) Calcular a trilha, setor e cabeçote para uma leitura de disco. 
(b) Manter uma cache dos blocos usados recentemente. 

(c) Enviar comandos nos registradores do dispositivo. 

(d) Verificar se o usuário pode utilizar o dispositivo. 

(e) Converter inteiros binários em ASCII para impressão. 


Por que os arquivos de saída da impressora normalmente são colocados em spool no disco antes de 
serem impressos? 


Dê um exemplo de impasse que poderia ocorrer no mundo físico. 


Considere a Figura 3-10. Suponha que no passo (o) C solicitasse $, em vez de solicitar R. Isso 
levaria a um impasse? Suponha que ele solicitasse $ e R. 


Dê uma boa olhada na Figura 3-13(b). Se D solicitar mais uma unidade, isso levará a um estado 
seguro ou a um estado inseguro? E se a requisição viesse de C, em vez de D? 


Todas as trajetórias na Figura 3-14 são horizontais ou verticais. Você consegue imaginar circuns- 
tâncias nas quais também fossem possíveis trajetórias diagonais? 


Suponha que o processo A na Figura 3-15 solicite a última unidade de fita. Essa ação leva a um 
impasse? 


Um computador tem seis unidades de fita, com n processos competindo por elas. Cada processo 
pode precisar de duas unidades. Para quais valores de n o sistema está livre de impasses? 


Um sistema pode estar em um estado que não cause impasse nem seja seguro? Se assim for, dê um 
exemplo. Caso contrário, prove que todos os estados causam impasse ou são seguros. 


Um sistema distribuído, usando caixas de correio, tem duas primitivas de IPC: SEND e RECEIVE. 
Esta última primitiva especifica um processo do qual vai receber e bloqueia, caso nenhuma men- 
sagem desse processo esteja disponível, mesmo que possa estar esperando mensagens de outros 
processos. Não existem recursos compartilhados, mas os processos precisam se comunicar fre- 
gientemente a respeito de outros assuntos. É possível haver um impasse? Discuta. 


Em um sistema de transferência eletrônica de fundos, existem centenas de processos idênticos que 
funcionam como segue. Cada processo lê uma linha de entrada especificando uma quantidade de 
dinheiro, a conta a ser creditada e a conta a ser debitada. Então, ele bloqueia as duas contas e trans- 
fere o dinheiro, liberando os bloqueios ao terminar. Com muitos processos executando em paralelo, 
existe o perigo muito real de que, tendo bloqueado a conta x, ele seja incapaz de bloquear y, pois 
y foi bloqueada por um processo que agora está esperando por x. Esboce um esquema que evite 
impasses. Não libere um registro de conta até que você tenha concluído as transações. (Em outras 
palavras, não são permitidas soluções que bloqueiam uma conta e então a liberam imediatamente, 
caso a outra esteja bloqueada.) 
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22. 


23. 


24. 


25. 


26. 


27. 


28. 


29. 


O algoritmo do banqueiro está sendo executado em um sistema com m classes de recurso e n pro- 

cessos. No limite de m e n grandes, o número de operações que devem ser efetuadas para verificar 
4 . b . ~ 

a segurança de um estado é proporcional a mn”. Quais são os valores de a e b? 


Considere o algoritmo do banqueiro da Figura 3-15. Suponha que os processos A e D mudem suas 
requisições para um (1, 2, 1, 0) e um (1, 2, 1, 0) adicionais, respectivamente. Essas requisições 
podem ser atendidas e o sistema ainda permanecer em um estado seguro? 


Cinderela e o príncipe estão se divorciando. Para dividir seus bens, eles concordaram com o se- 
guinte algoritmo. Toda manhã, cada um pode mandar uma carta para o advogado do outro pedindo 
um item dos bens. Como demora um dia para as cartas serem entregues, eles concordaram que, se 
ambos descobrirem que pediram o mesmo item no mesmo dia, no dia seguinte eles enviarão uma 
carta cancelando o pedido. Dentre seus bens está seu cachorro, Woofer, a casinha de Woofer, seu 
canário, Tweeter, e a gaiola de Tweeter. Os animais amam suas casas, de modo que ficou acertado 
que qualquer divisão de bens separando um animal de sua casa é inválida, exigindo que a divisão 
inteira recomece desde o início. Tanto a Cinderela como o príncipe querem Woofer desperadamen- 
te. Então, eles saem de férias (separados), tendo cada um programado um computador pessoal para 
tratar da negociação. Quando eles voltam das férias, os computadores ainda estão negociando. Por 
quê? É possível ocorrer um impasse? É possível ocorrer inanição (esperar para sempre)? Discuta. 


Considere um disco com 1000 setores/trilha de 512 bytes, oito trilhas por cilindro e 10.000 cilin- 
dros, com um tempo de rotação de 10 ms. O tempo de busca de trilha para trilha é de 1 ms. Qual é 
a taxa de rajada (burst) máxima suportável? Quanto tempo pode durar uma rajada assim? 


Uma rede local é usada como segue. O usuário executa uma chamada de sistema para enviar pa- 
cotes de dados na rede. O sistema operacional copia os dados em um buffer do núcleo. Então, ele 
copia os dados na placa controladora de rede. Quando todos os bytes estão em segurança dentro 
da controladora, eles são enviados pela rede a uma velocidade de 10 megabits/s. A controladora de 
rede receptora armazena cada bit um microssegundo após ser enviado. Quando o último bit chega, 
a CPU de destino é interrompida e o núcleo copia o pacote que acabou de chegar em um buffer para 
inspecioná-lo. Quando tiver descoberto para qual usuário é o pacote, o núcleo copia os dados no 
espaço de usuário. Se presumirmos que cada interrupção e seu processamento associado demoram 
1 ms, que os pacotes têm 1024 bytes (ignore os cabeçalhos) e que a cópia de um byte leva 1 ms, 
qual é a velocidade máxima com que um processo pode enviar dados para outro? Suponha que o 
remetente seja bloqueado até que o trabalho tenha terminado no lado receptor e que um sinal de 
confirmação (ack) seja devolvido. Por simplicidade, suponha que o tempo para obter o sinal de 
confirmação é tão pequeno que pode ser ignorado. 


O formato de mensagem da Figura 3-17 é usado para enviar mensagens de requisição para drivers de 
dispositivos de bloco. Alguns campos poderiam ser omitidos para dispositivos de caractere? Quais? 


Requisições de disco chegam no driver para os cilindros 10, 22, 20, 2, 40, 6 e 38, nessa ordem. 
Uma busca leva 6 ms por cilindro movido. Quanto tempo de busca é necessário para: 


(a) Primeiro a chegar, primeiro a ser atendido. 
(b) Cilindro mais próximo em seguida. 
(c) Algoritmo do elevador (inicialmente movendo-se para cima). 


Em todos os casos, o braço está inicialmente no cilindro 20. 


Um vendedor de computadores pessoais em visita a uma universidade no sudoeste de Amsterdã 
comentava, durante sua apresentação, que sua empresa tinha se esforçado ao máximo para tornar 
a versão do UNIX muito rápida. Como exemplo, ele dizia que o driver de disco deles usava o al- 
goritmo do elevador e também enfileirava várias requisições dentro de um cilindro pela ordem dos 
setores. Um aluno, Harry Hacker, ficou impressionado e comprou um computador. Levou-o para 
casa e escreveu um programa para ler aleatoriamente 10.000 blocos espalhados pelo disco. Para 
seu espanto, o desempenho que mediu foi idêntico ao que seria esperado do algoritmo do primeiro 
a chegar, primeiro a ser atendido. O vendedor estava mentindo? 
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36. 
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42. 


Um processo do UNIX tem duas partes: a parte do usuário e a parte do núcleo. A parte do núcleo é 
como uma sub-rotina ou como uma co-rotina? 


A rotina de tratamento de interrupção de relógio em determinado computador exige 2 ms (incluin- 
do a sobrecarga do chaveamento de processos) por tique de relógio. O relógio funciona a 60 Hz. 
Que fração da CPU é dedicada ao relógio? 


No texto, foram dados dois exemplos de temporizadores de cão de guarda: sincronização na inicia- 
lização do motor de disquete e permissão para retorno de carro em terminais de impressão. Dê um 
terceiro exemplo. 


Por que os terminais RS232 são baseados em interrupção, mas os terminais mapeados em memória 
não? 


Considere o funcionamento de um terminal. O driver gera um caractere na saída e então é bloque- 
ado. Quando o caractere tiver sido impresso, uma interrupção ocorre e uma mensagem é enviada 
para o driver bloqueado, o qual gera na saída o próximo caractere e então é novamente bloqueado. 
Se o tempo para passar uma mensagem, gerar a saída de um caractere e bloquear é de 4 ms, esse 
método funciona bem em linhas de 110 baud? E em linhas de 4800 baud? 


Um terminal de mapa de bits contém 1200 por 800 pixels. Para rolar uma janela, a CPU (ou a 
controladora) deve mover todas as linhas de texto para cima, copiando seus bits de uma parte para 
outra da RAM de vídeo. Se uma janela em particular tem 66 linhas de altura por 80 caracteres de 
largura (5280 caracteres no total) e o espaço reservado para um caractere é de 8 pixels de largura 
por 12 pixels de altura, quanto tempo demora para rolar a janela inteira a uma velocidade de cópia 
de 500 ns por byte? Se todas as linhas têm 80 caracteres de comprimento, qual é a taxa de trans- 
missão de dados equivalente do terminal? Colocar um caractere na tela exige 50 ms. Agora, calcule 
a taxa de transmissão de dados para o mesmo terminal colorido, com 4 bits/pixel. (Colocar um 
caractere na tela exige agora 200 ms.) 


Por que os sistemas operacionais fornecem caracteres de escape, como o CTRL-V no MINIX? 


Após receber um caractere CTRL-C (SIGINT), o driver do MINIX descarta toda a saída corrente- 
mente enfileirada para esse terminal. Por quê? 


Muitos terminais RS232 têm sequências de escape para excluir a linha corrente e mover todas as li- 
nhas que estão abaixo dela uma linha para cima. Como você acha que esse recurso é implementado 
dentro do terminal? 


No monitor em cores original do IBM PC, escrever na RAM de vídeo em qualquer momento que 
não seja durante o retraço vertical do feixe do CRT fazia manchas horríveis aparecerem por toda a 
tela. Uma imagem de tela tem 25 por 80 caracteres, cada um dos quais se encaixa em um espaço de 
8 pixels por 8 pixels. Cada linha de 640 pixels é desenhada em uma única varredura horizontal do 
feixe, o que leva 63,6 ms, incluindo o retraço horizontal. A tela é redesenhada 60 vezes por segun- 
do, cada uma das quais exige um período de retraço vertical para fazer o feixe voltar ao topo. Em 
que fração do tempo a RAM de vídeo está disponível para ser escrita? 


Escreva um driver gráfico para o monitor em cores da IBM ou para algum outro monitor de mapa 
de bits conveniente. O driver deve aceitar comandos para ativar e desativar pixels individuamente, 
mover retângulos pela tela e quaisquer outros recursos que você ache interessantes. Os programas 
de usuário fazem a interface com o driver abrindo /dev/graphics e escrevendo comandos aí. 


Modifique o driver de disquete do MINIX para colocar uma trilha por vez na cache. 


Implemente um driver de disquete que funcione como um dispositivo de caractere, em vez de dis- 
positivo de bloco, para ignorar a cache de blocos do sistema de arquivos. Desse modo, os usuários 
podem ler grandes trechos de dados do disco, os quais passam diretamente para o espaço de usuá- 
rio por meio de DMA, aumentando substancialmente o desempenho. Esse driver seria interessante 
principalmente para programas que precisam ler bits no disco de forma “bruta”, sem considerar o 
sistema de arquivos. Os verificadores de sistema de arquivos entram nessa categoria. 
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43. 
44. 


45. 


Implemente a chamada de sistema PROFIL do UNIX, que está faltando no MINIX. 


Modifique o driver de terminal de modo que, além de ter uma tecla especial para apagar o caractere 
anterior, exista uma tecla para apagar a palavra anterior. 


Um novo dispositivo de disco rígido com mídia removível foi adicionado em um sistema MINIX 3. 
Esse dispositivo deve atingir a velocidade de rotação sempre que as mídias são trocadas e o tempo 
de giro é muito longo. Já se sabe que as trocas de mídia serão feitas frequentemente, enquanto o 
sistema estiver executando. De repente, a rotina waitfor em at wini.c torna-se insatisfatória. Proje- 
te uma nova rotina waitfor na qual, se o padrão de bits que está sendo esperado não for encontrado 
após 1 segundo de espera ativa, o código entre em uma fase na qual o driver de disco ficará em 
repouso por 1 segundo, testará a porta e voltará a entrar em repouso por mais um segundo, até que 
o padrão buscado seja encontrado ou que o período de TIMEOUT predefinido expire. 


GERENCIAMENTO DE MEMÓRIA 


A memória é um recurso importante que deve ser cuidadosamente gerenciado. Embora, hoje 
em dia, um computador doméstico médio tenha duas mil vezes mais memória do que o IBM 
7094 (o maior computador do mundo no início dos anos 60), os programas e os dados que 
eles devem manipular também cresceram tremendamente. Parafraseando a lei de Parkinson, 
“os programas e seus dados aumentam de forma a ocupar toda a memória disponível para 
contê-los”. Neste capítulo, estudaremos o modo como os sistemas operacionais gerenciam a 
memória. 

Teoricamente, o que todo programador gostaria é de uma memória infinitamente gran- 
de, infinitamente rápida e que também fosse não-volátil; isto é, que não perdesse seu con- 
teúdo na falta de energia elétrica. E já que estamos nessa, por que não pedir também que 
fosse barata? Infelizmente, a tecnologia não consegue tornar esses sonhos uma realidade. 
Consegiientemente, a maioria dos computadores tem uma hierarquia de memória, com uma 
pequena quantidade de memória cache, volátil, muito rápida e cara; centenas de megabytes 
de memória principal volátil (RAM) de velocidade e preço médios; e dezenas ou centenas de 
gigabytes de armazenamento em disco, não-volátil, lento e barato. A tarefa do sistema opera- 
cional é coordenar a utilização desses diferentes tipos de memória. 

A parte do sistema operacional que gerencia a hierarquia de memória é chamada de 
gerenciador de memória. Sua tarefa é monitorar as partes da memória que estão em uso e 
as que não estão, alocar memória para os processos quando eles precisarem dela e liberá-la 
quando terminam, e gerenciar a transferência (swapping) entre a memória principal e o disco, 
quando a memória principal for pequena demais para conter todos os processos. Na maioria 
dos sistemas (mas não no MINIX 3), o gerenciador de memória fica no núcleo. 

Neste capítulo, investigaremos vários esquemas de gerenciamento de memória diferen- 
tes, variando desde o muito simples até o altamente sofisticado. Começaremos do princípio 
e veremos primeiro o sistema de gerenciamento de memória mais simples possível e, então, 
progrediremos gradualmente para os cada vez mais elaborados. 

Conforme mencionamos no Capítulo 1, a história tem a tendência de se repetir no mun- 
do da computação: inicialmente, o software de um minicomputador era como o software de 
um computador de grande porte e, posteriormente, o software de um computador pessoal era 
como o software de um minicomputador. Agora o ciclo está se repetindo com os palmtops, 
PDAs e sistemas embarcados. Nesses sistemas, ainda estão em uso esquemas de gerencia- 
mento de memória simples. Por isso, ainda vale a pena estudá-los. 
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GERENCIAMENTO BÁSICO DE MEMÓRIA 


Os sistemas de gerenciamento de memória podem ser divididos em duas classes fundamen- 
tais: aqueles que alternam os processos entre a memória principal e o disco durante a execu- 
ção (swapping) e aqueles que não alternam. Estes últimos são mais simples, portanto, estuda- 
remos primeiro. Posteriormente, neste capítulo, examinaremos o swapping e a paginação. Ao 
longo de todo este capítulo o leitor deverá lembrar que swapping e paginação são artifícios 
usados para contornar a falta de memória principal suficiente para conter todos os programas 
e dados simultaneamente. Se a memória principal ficar tão grande que haja realmente o su- 
ficiente, os argumentos a favor de um tipo de esquema de gerenciamento de memória ou de 
outro podem se tornar obsoletos. 

Por outro lado, conforme mencionamos anteriormente, o software parece crescer tão 
rápido quanto a memória; portanto, o gerenciamento eficiente da memória sempre pode ser 
necessário. Nos anos 80, havia muitas universidades que usavam um sistema de comparti- 
lhamento de tempo com dezenas de usuários (mais ou menos satisfeitos), em um VAX de 4 
MB. Agora, a Microsoft recomenda ter pelo menos 128 MB para um sistema Windows XP 
monousuário. A tendência em direção à multimídia impõe ainda mais exigências sobre a me- 
mória; portanto, um bom gerenciamento de memória provavelmente ainda vai ser necessário 
no mínimo por mais uma década. 


Monoprogramação sem swapping ou paginação 

O esquema de gerenciamento de memória mais simples possível é executar apenas um pro- 
grama por vez, compartilhando a memória entre esse programa e o sistema operacional. Três 
variações sobre esse tema aparecem na Figura 4-1. O sistema operacional pode estar na par- 
te inferior da memória na RAM (Random Access Memory — memória de acesso aleatório), 
como se vê na Figura 4-1(a), pode estar na ROM (Read-Only Memory — memória somente 
de leitura), na parte superior da memória, como se vê na Figura 4-1(b), ou os drivers de dis- 
positivo podem estar na parte superior da memória em uma ROM e o restante do sistema na 
RAM abaixo dela, como se vê na Figura 4-1(c). O primeiro modelo foi usado inicialmente em 
computadores de grande porte e em minicomputadores, mas hoje em dia raramente é usado. 
O segundo modelo é usado em alguns palmtops e em sistemas embarcados. O terceiro mo- 
delo foi usado pelos primeiros computadores pessoais (por exemplo, executando MS-DOS), 
onde a parte do sistema que fica na ROM é chamada de BIOS (Basic Input Output System 
— sistema básico de entrada e saída). 


OxFFF-... 


Sistema Drivers de 
operacional dispositivo em ROM 


em ROM 
Programa 


de usuário Programa 


de usuário 


Programa 
de usuário 


Sistema 
operacional 
em RAM 


Sistema 
operacional 
em RAM 


(a) (b) (c) 


Figura 4-1 Três maneiras simples de organizar a memória com um sistema operacional e 
um único processo de usuário. Também existem outras possibilidades. 
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Quando o sistema é organizado dessa maneira, apenas um processo por vez pode estar 
em execução. Assim que o usuário digita um comando, o sistema operacional copia o pro- 
grama solicitado do disco para a memória e o executa. Quando o processo termina, o sistema 
operacional exibe um caractere de aviso e espera por um novo comando. Ao receber o coman- 
do, ele carrega um novo programa na memória, sobrescrevendo o primeiro. 


Multiprogramação com partições fixas 


A não ser em sistemas embarcados muito simples, a monoprogramação dificilmente é usada 
hoje em dia. A maioria dos sistemas modernos permite que vários processos sejam executa- 
dos ao mesmo tempo. Ter vários processos executando simultaneamente significa que, quan- 
do um processo está bloqueado esperando o término de uma operação de E/S, outro processo 
pode usar a CPU. Assim, a multiprogramação aumenta a utilização da CPU. Os servidores 
de rede sempre têm a capacidade de executar vários processos (para diferentes clientes) ao 
mesmo tempo, mas hoje em dia a maioria das máquinas clientes (isto é, de desktop) também 
tem essa capacidade. 

A maneira mais fácil de obter multiprogramação é simplesmente dividir a memória em 
até n partições (possivelmente de tamanhos diferentes). Esse particionamento pode ser feito 
manualmente, por exemplo, quando o sistema é inicializado. 

Quando chega um job, ele pode ser colocado na fila de entrada da menor partição gran- 
de o bastante para contê-lo. Como as partições são fixas nesse esquema, todo espaço não uti- 
lizado por um job em uma partição é desperdiçado, enquanto esse job é executado. Na Figura 
4-2(a), vemos como é esse sistema de partições fixas e filas de entrada separadas. 


Várias filas 
de entrada 800K 
700K 
: 5 
entrada única 
400K 
200K 
z 100K f 
Sistema Sistema 
operacional 0 operacional 


(a) (b) 


Figura 4-2 (a) Partições fixas de memória com filas de entrada separadas para cada parti- 
ção. (b) Partições fixas de memória com uma única fila de entrada. 


A desvantagem de ordenar os jobs recebidos em filas separadas se torna evidente quan- 
do a fila de uma partição grande está vazia, mas a de uma partição pequena está cheia, como 
acontece nas partições 1 e 3 da Figura 4-2(a). Aqui, os jobs pequenos têm de esperar para en- 
trar na memória, mesmo havendo muita memória livre. Uma organização alternativa é manter 
uma única fila, como na Figura 4-2(b). Quando uma partição fica livre, o job mais próximo do 
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início da fila, e que caiba na partição vazia, poderia ser carregado nessa partição e executado. 
Como é indesejável desperdiçar uma partição grande com um job pequeno, uma estratégia 
diferente é, quando uma partição ficar livre, pesquisar a fila de entrada inteira e escolher o 
maior job que caiba nela. Note que este último algoritmo discrimina os jobs pequenos, tra- 
tando-os como indignos de terem uma partição inteira, embora normalmente seja desejável 
fornecer o melhor serviço para jobs menores (frequentemente jobs interativos) e não o pior. 

Uma saída é dispor de pelo menos uma partição pequena. Essa partição permitirá que os 
jobs pequenos sejam executados sem precisar alocar uma partição grande para eles. 

Outra estratégia é ter uma regra dizendo que um job pronto para executar não pode ser 
preterido mais do que k vezes. Sempre que for preterido, ele recebe um ponto. Quando tiver 
adquirido k pontos, ele não poderá ser preterido novamente. 

Esse sistema, com partições fixas configuradas de manhã pelo operador e não mais 
alteradas depois disso, foi usado durante muitos anos pelo OS/360 em computadores IBM de 
grande porte. Ele se chamava MFT (multiprogramação com um número fixo de tarefas ou 
OS/MFT). Ele é simples de entender e igualmente simples de implementar: os jobs (tarefas) 
recebidos são enfileirados até que uma partição conveniente esteja disponível, no momento 
em que o job é carregado nessa partição e executado até terminar. Entretanto, hoje em dia 
poucos (se houver) sistemas operacionais suportam esse modelo, mesmo em sistemas de lote 
de computadores de grande porte. 


Realocação e proteção 

A multiprogramação introduz dois problemas básicos que devem ser resolvidos: realocação e 
proteção. Veja a Figura 4-2. A partir da figura fica claro que diferentes tarefas serão executadas 
em diferentes endereços. Quando um programa é ligado (isto é, o programa principal, as fun- 
ções escritas pelo usuário e as funções de biblioteca são combinados em um único espaço de 
endereçamento), o ligador deve saber em que endereço o programa começará na memória. 

Por exemplo, suponha que a primeira instrução seja uma chamada para uma função 
no endereço absoluto 100, dentro do arquivo binário produzido pelo ligador. Se esse progra- 
ma for carregado na partição 1 (no endereço 100K), essa instrução pulará para o endereço 
absoluto 100, que está dentro do sistema operacional. O que é preciso é uma chamada para 
100K + 100. Se o programa for carregado na partição 2, ele deverá ser executado como uma 
chamada para 200K + 100 e assim por diante. Esse problema é conhecido como problema da 
realocação. 

Uma possível solução é modificar realmente as instruções quando o programa é carrega- 
do na memória. Os programas carregados na partição 1 têm 100K somados a cada endereço, 
os programas carregados na partição 2 têm 200K somados aos endereços e assim por diante. 
Para realizar a realocação dessa forma, durante a carga, o ligador precisa incluir no programa 
binário uma lista, ou um mapa de bits, informando quais palavras do programa são endereços 
a serem corrigidas (realocadas) e quais são códigos de operação, constantes ou outros itens 
que não devem ser realocadas. O OS/MFT funcionava assim. 

A realocação durante a carga não resolve o problema da proteção. Um programa mal- 
doso sempre pode construir uma nova instrução e pular para ela. Como os programas nesse 
sistema usam endereços de memória absolutos em vez de endereços relativos ao valor de um 
registrador, não há como impedir que um programa construa uma instrução que leia ou escre- 
va qualquer palavra na memória. Nos sistemas multiusuário, é altamente indesejável permitir 
que os processos leiam e escrevam na memória pertencente a outros usuários. 

A solução escolhida pela IBM para proteger o 360 foi dividir a memória em blocos de 
2 Kbytes e atribuir um código de proteção de 4 bits a cada bloco. O PSW (Program Status 
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Word) continha uma chave de 4 bits. O hardware do 360 detectava qualquer tentativa por par- 
te de um processo em execução de acessar memória cujo código de proteção fosse diferente 
da chave PSW. Como apenas o sistema operacional podia mudar os códigos de proteção e 
a chave, os processos de usuário eram impedidos de interferir uns nos outros e no sistema 
operacional em si. 

Uma solução alternativa para os problemas de realocação e proteção é fornecer dois 
registradores de hardware especiais, chamados de base e limite. Quando um processo é es- 
calonado, o registrador de base é carregado com o endereço do início de sua partição e o 
registrador de limite é carregado com o tamanho dessa partição. Todo endereço de memória 
gerado tem o conteúdo do registrador de base automaticamente somado a ele, antes de ser 
enviado para a memória. Assim, se o registrador de base contém o valor 100K, uma instrução 
CALL 100 é efetivamente transformada em uma instrução CALL 100K + 100, sem que a 
instrução em si seja modificada. Os endereços também são verificados em relação ao regis- 
trador de limite para garantir que não tentem endereçar memória fora da partição corrente. O 
hardware protege os registradores de base e de limite para impedir que programas de usuário 
os modifiquem. 

Uma desvantagem desse esquema é a necessidade de efetuar uma adição e uma compa- 
ração em cada referência de memória. As comparações podem ser feitas rapidamente, mas as 
adições são lentas, devido ao tempo de propagação do transporte, a não ser que sejam usados 
circuitos de adição especiais. 

O CDC 6600 — o primeiro supercomputador do mundo — usava esse esquema. A CPU 
Intel 8088 usada pelo IBM PC original utilizava uma versão ligeiramente menos eficiente 
desse esquema — com registradores de base, mas sem registradores de limite. Atualmente, 
poucos computadores o utilizam. 


SWAPPING 


Com um sistema de lotes, organizar a memória em partições fixas é simples e eficiente. Cada 
job é carregado em uma partição quando chega no começo da fila. O job permanece na me- 
mória até que tenha terminado. Contanto que jobs suficientes possam ser mantidos em memó- 
ria para conservar a CPU ocupada o tempo todo, não há porque usar algo mais complicado. 

Com sistemas de compartilhamento de tempo a situação é diferente. Às vezes, não há 
memória principal suficiente para conter todos os processos correntemente ativos, de modo 
que os processos excedentes devem ser mantidos no disco e trazidos para execução dinami- 
camente. 

Podem ser usadas duas estratégias gerais de gerenciamento de memória, dependendo 
(em parte) do hardware disponível. A estratégia mais simples, chamada de swapping, consiste 
em trazer cada processo em sua totalidade, executá-lo por algum tempo e, então, colocá-lo de 
volta no disco. A outra estratégia, chamada de memória virtual, permite que os programas 
sejam executados mesmo quando estão apenas parcialmente na memória principal. A seguir, 
estudaremos o swapping; na Seção 4.3, examinaremos a memória virtual. 

O funcionamento de um sistema de swapping está ilustrado na Figura 4-3. Inicialmente, 
apenas o processo A está na memória. Então, os processos B e C são criados ou recuperados 
do disco. Na Figura 4-3(d), A é enviado para o disco. Então, D entra e B sai. Finalmente, A 
entra outra vez. Como A está agora em um local diferente, os endereços contidos nele devem 
ser realocados, ou pelo software, quando ele é colocado na memória, ou (mais provavelmen- 
te) pelo hardware, durante a execução do programa. 

A principal diferença entre as partições fixas da Figura 4-2 e as partições variáveis da 
Figura 4-3 é que, nestas, o número, a posição e o tamanho das partições variam dinamica- 
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mente à medida que os processos entram e saem, ao passo que, nas primeiras, as partições são 
fixas. A flexibilidade de não estar vinculado a uma determinada partição, que pode ser grande 
ou pequena demais, melhora a utilização da memória, mas também complica a alocação e a 
liberação da memória, assim como seu monitoramento. 
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Sistema Sistema Sistema 
operacional operacional] |operacional 
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Figura 4-3 A alocação da memória muda à medida que os processos entram e saem da me- 
mória. As regiões sombreadas representam memória não utilizada. 
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Quando o swapping cria várias lacunas na memória, é possível combiná-las em apenas 
uma lacuna grande, movendo todos os processos o mais para baixo possível. Essa técnica é 
conhecida como compactação de memória. Normalmente ela não é feita porque exige muito 
tempo de CPU. Por exemplo, em uma máquina de 1 GB, que executa cópia com uma veloci- 
dade de 2 GB/s (0,5 ns/byte), demoraria cerca de 0,5 s para compactar toda a memória. Isso 
pode não parecer muito tempo, mas seria perceptível para um usuário que estivesse vendo 
um vídeo. 

Um ponto que merece ser considerado é a quantidade de memória que deve ser alocada 
para um processo quando ele é criado ou recuperado do disco. Se os processos são criados 
com um tamanho fixo que nunca muda, então a alocação é simples: o sistema operacional 
aloca exatamente o que é necessário, nem mais nem menos. 

Entretanto, se os segmentos de dados dos processos podem crescer, por exemplo, pela 
alocação dinâmica de memória a partir de um heap, como acontece em muitas linguagens de 
programação, ocorre um problema quando um processo tentar crescer. Se houver uma lacuna 
adjacente ao processo, ela poderá ser alocada e o processo poderá crescer utilizando a lacuna. 
Por outro lado, se o processo for adjacente a outro processo, o processo em crescimento terá 
de ser movido para uma lacuna na memória que seja grande o suficiente para ele ou, então, 
um ou mais processos terão de ser enviados para o disco para criar uma lacuna suficientemen- 
te grande. Se um processo não puder crescer na memória e a área de swap no disco estiver 
cheia, o processo terá de esperar ou ser eliminado. 

Se a expectativa for de que a maioria dos processos crescerá quando executados, pro- 
vavelmente será uma boa idéia alocar um pouco de memória extra, quando um processo for 
colocado ou movido da memória, para reduzir a sobrecarga associada à movimentação ou 
swapping de processos que não cabem mais em sua memória alocada. Entretanto, ao fazer 
swapping dos processos no disco, apenas a memória realmente em uso deverá ser transferida; 
é um desperdício transferir a memória extra. Na Figura 4-4(a), vemos uma configuração de 
memória na qual o espaço para crescimento foi alocado para dois processos. 
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Figura 4-4 (a) Alocando espaço para um segmento de dados em crescimento. (b) Alocando 
espaço para uma pilha em crescimento e para um segmento de dados em crescimento. 


Se os processos puderem ter dois segmentos em crescimento, por exemplo, o segmento 
de dados sendo usado como heap para variáveis alocadas e liberadas dinamicamente e um 
segmento de pilha para as variáveis locais e endereços de retorno, sugere-se uma organização 
alternativa, a saber, a da Figura 4-4(b). Nessa figura, vemos que cada processo ilustrado tem 
uma pilha, no início de sua memória alocada, que está crescendo para baixo, e um segmento 
de dados imediatamente após o texto do programa, que está crescendo para cima. A memória 
entre eles pode ser usada por qualquer um dos dois segmentos. Se ela acabar, um dos dois 
processos terá de ser movido para uma lacuna com espaço suficiente, sendo retirado da me- 
mória até que uma lacuna grande o bastante possa ser criada, ou ser eliminado. 


Gerenciamento de memória com mapas de bits 


Quando a memória é atribuída dinamicamente, o sistema operacional precisa gerenciá-la. Em 
termos gerais, há duas maneiras de monitorar a utilização da memória: mapas de bits e listas 
de regiões livres. Nesta seção e na próxima, veremos esses dois métodos. 

Com um mapa de bits, a memória é dividida em unidades de alocação, talvez tão pe- 
quenas quanto algumas palavras e talvez tão grandes quanto vários quilobytes. Há um bit no 
mapa de bits, correspondendo a cada unidade de alocação, que é 0 se a unidade estiver livre e 
1 se estiver ocupada (ou vice-versa). A Figura 4-5 mostra parte da memória e o mapa de bits 
correspondente. 

O tamanho da unidade de alocação é uma importante questão de projeto. Quanto menor 
for a unidade de alocação, maior será o mapa de bits. Entretanto, mesmo com uma unidade de 
alocação tão pequena quanto 4 bytes, 32 bits de memória exigirão apenas 1 bit do mapa. Uma 
memória de 32n bits usará n bits do mapa; portanto, o mapa de bits ocupará apenas 1/33 da 
memória. Se for escolhida uma unidade de alocação grande, o mapa de bits será menor, mas 
uma quantidade de memória apreciável poderá ser desperdiçada na última unidade alocada ao 
processo, isso se o tamanho do processo não for um múltiplo exato da unidade de alocação. 

Um mapa de bits proporciona uma maneira simples de monitorar palavras de memória 
em uma quantidade fixa de memória, pois o tamanho do mapa de bits depende apenas do 
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Figura 4-5 (a) Uma parte da memória com cinco processos e três lacunas. Os tracinhos 
mostram as unidades de alocação de memória. As regiões sombreadas (0 no mapa de bits) 
estão livres. (b) O mapa de bits correspondente. (c) As mesmas informações como uma lista. 


tamanho da memória e da unidade de alocação. O principal problema disso é que, quando for 
decidido trazer um processo de k unidades para a memória, o gerenciador de memória deverá 
pesquisar o mapa de bits para encontrar uma sequência de k bits em O consecutivos no mapa. 
Pesquisar um mapa de bits para encontrar uma sequência de determinado comprimento é uma 
operação lenta (porque a segiiência pode se esparramar nos limites de palavra do mapa): esse 
é um argumento contra os mapas de bits. 


Gerenciamento de memória com listas encadeadas 


Outra maneira de monitorar a memória é manter uma lista encadeada de segmentos de memó- 
ria alocados e livres, onde um segmento é um processo ou uma lacuna entre dois processos. 
A memória da Figura 4-5(a) está representada na Figura 4-5(c) como uma lista encadeada de 
segmentos. Cada entrada na lista especifica uma lacuna (L) ou processo (P), o endereço em 
que inicia, o comprimento e um ponteiro para a próxima entrada. 

Nesse exemplo, a lista de segmentos está ordenada pelo endereço. Ordenar dessa ma- 
neira tem a vantagem de que, quando um processo termina, ou é enviado para o disco, atu- 
alizar a lista é simples. Normalmente, um processo que está terminando tem dois vizinhos 
(exceto quando está no início ou no final da memória) que podem ser processos ou lacunas, 
levando às quatro combinações mostradas na Figura 4-6. Na Figura 4-6(a), atualizar a lista 
exige substituir um P por um L. Na Figura 4-6(b) e também na Figura 4-6(c), duas entradas 
são aglutinadas em uma e a lista se torna uma única entrada mais curta. Na Figura 4-6(d), 
três entradas são aglutinadas e dois itens são removidos da lista. Como a entrada da tabela de 


Antes que X termine Depois que X termina 


se torna 


xls] 
o ZA x ZA son II 


Figura 4-6 Quatro combinações de vizinhos para o processo que está terminando, X. 
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processos referente ao processo que está terminando normalmente apontará para a entrada na 
lista do próprio processo, pode ser mais conveniente ter uma lista duplamente encadeada, em 
vez da lista encadeada simples da Figura 4-5(c). Essa estrutura torna mais fácil encontrar a 
entrada anterior e ver se um aglutinamento é possível. 

Quando os processos e lacunas são mantidos em uma lista ordenada pelo endereço, vá- 
rios algoritmos podem ser usados para alocar memória para um processo recentemente criado 
(ou para um processo já existente que esteja sendo sofrendo swap do disco para a memória). 
Supomos que o gerenciador de memória sabe qual é a quantidade de memória a ser alocada. 
O algoritmo mais simples é o do o primeiro que couber (first fit). O gerenciador de proces- 
sos percorre toda a lista de segmentos até encontrar uma lacuna que seja grande o suficiente. 
Então, a lacuna é dividida em duas partes, uma para o processo e uma para a memória não 
utilizada, exceto no caso estatisticamente improvável em que caiba justamente. O algoritmo 
do o primeiro que couber é rápido, pois pesquisa o mínimo possível. 

Uma variação de menor interesse do algoritmo do o primeiro que couber é o do o pró- 
ximo que melhor couber (next fit). Ele funciona da mesma maneira que o algoritmo do o 
primeiro que couber exceto que procura até encontrar uma lacuna conveniente e memoriza 
essa posição. Na próxima vez que for chamado para encontrar uma lacuna, ele inicia a pes- 
quisar a lista a partir de onde estava da última vez, em vez de começar do início, como acon- 
tece com o algoritmo do o primeiro que couber. Simulações feitas por Bays (1977) mostram 
que o algoritmo do o próximo que melhor couber oferece um desempenho ligeiramente pior 
do que o do o primeiro que couber. 

Outro algoritmo conhecido é o do que melhor couber (best fit). Esse algoritmo pes- 
quisa a lista inteira e pega a menor lacuna que seja adequada. Em vez de dividir uma lacuna 
grande, que poderia ser necessária posteriormente, o algoritmo do o que melhor couber tenta 
encontrar uma lacuna cujo tamanho seja próximo ao realmente necessário. 

Como exemplo dos algoritmos do o primeiro que couber e do o que melhor couber, 
considere a Figura 4-5 novamente. Se for necessário um bloco de tamanho 2, o algoritmo 
do o primeiro que couber alocará a lacuna que está em 5, mas o algoritmo do o que melhor 
couber alocará a lacuna que está em 18. 

O algoritmo do o que melhor couber é mais lento do que o algoritmo do o primeiro 
que couber, pois precisa pesquisar a lista inteira sempre que é chamado. Um tanto surpre- 
endentemente, ele também resulta em mais memória desperdiçada do que o algoritmo do o 
primeiro que couber ou do o próximo que melhor couber, pois tende a preencher a memória 
com lacunas minúsculas e inúteis. Em média, o algoritmo do o primeiro que couber gera 
lacunas maiores. 

Para contornar o problema da divisão em correspondências exatas em um processo e 
de uma lacuna minúscula, pode-se pensar no algoritmo do o que pior couber (worst fit); 
isto é, pegar sempre a maior lacuna disponível, de modo que a lacuna dividida será grande o 
bastante para ser útil. Resultados de simulação mostram que o algoritmo do o que pior couber 
também não é uma idéia muito boa. 

A velocidade de todos os quatro algoritmos pode aumentar mantendo-se listas sepa- 
radas para processos e lacunas. Desse modo, todos eles dedicam toda a sua energia para 
inspecionar lacunas e não processos. O preço inevitável a ser pago por essa maior velocidade 
na alocação é a complexidade adicional e o atraso ao liberar a memória, pois um segmento 
liberado precisa ser removido da lista de processos e inserido na lista de lacunas. 

Se forem mantidas listas distintas para processos e lacunas, a lista de lacunas poderá ser 
mantida ordenada pelo tamanho, para tornar o algoritmo o que melhor couber mais rápido. Quan- 
do o algoritmo o que melhor couber pesquisa uma lista de lacunas da menor para a maior, assim 
que encontra uma lacuna adequada ele já sabe que ela é a menor possível; daí, o que melhor cou- 
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ber. Não é necessária mais nenhuma pesquisa, como acontece no esquema da lista simples. Com 
uma lista de lacunas ordenada pelo tamanho, os algoritmos do o primeiro que couber e do o que 
melhor couber são igualmente rápidos e o algoritmo do o próximo que couber é inútil. 

Quando as lacunas são mantidas em listas separadas dos processos, é possível uma pe- 
quena otimização. Em vez de ter um conjunto de estruturas de dados separadas para manter 
a lista de lacunas, como foi feito na Figura 4-5(c), as próprias lacunas podem ser usadas. A 
primeira palavra de cada lacuna poderia ser o tamanho da lacuna e a segunda palavra poderia 
ser um ponteiro para a entrada seguinte. Os nós da lista da Figura 4-5(c), que exige três pala- 
vras e um bit (P/L), não são mais necessários. 

Um outro algoritmo de alocação é o do o que mais rápido couber (quick fit), que man- 
tém listas separadas para alguns dos tamanhos mais comuns solicitados. Por exemplo, pode- 
ria haver uma tabela com n entradas, na qual a primeira entrada é um ponteiro para o início 
de uma lista de lacunas de 4 KB, a segunda entrada é um ponteiro para uma lista de lacunas 
de 8 KB, a terceira entrada é um ponteiro para lacunas de 12 KB e assim por diante. Lacunas 
de, digamos, 21 KB, poderiam ser colocadas na lista de 20 KB ou em uma lista especial de 
lacunas de tamanho peculiar. Com o algoritmo do o que mais rápido couber, encontrar uma 
lacuna do tamanho exigido é extremamente rápido, mas ele tem a mesma desvantagem de 
todos os esquemas que ordenam pelo tamanho da lacuna; a saber, quando um processo termi- 
na ou é transferido para o disco, é dispendioso localizar seus vizinhos para ver se é possível 
aglutinar lacunas. Se a aglutinação não for feita, a memória se fragmentará rapidamente em 
um grande número de lacunas pequenas, nas quais nenhum processo caberá. 


MEMÓRIA VIRTUAL 


Há muitos anos, as pessoas defrontaram-se pela primeira vez com programas que eram gran- 
des demais para caber na memória disponível. A solução normalmente adotada era dividir 
o programa em partes chamadas de overlays (sobreposição). O overlay O era posto em exe- 
cução primeiro. Quando terminava, ele chamava outro overlay. Alguns sistemas de overlay 
eram altamente complexos, permitindo a existência de vários overlays na memória simulta- 
neamente. Os overlays eram mantidos no disco e levados para a memória e trazidos de volta 
dinamicamente pelo sistema operacional, conforme fossem necessários. 

Embora o trabalho real de alternância de overlays entre a memória e o disco fosse feito 
pelo sistema, a decisão sobre como dividir o programa em partes tinha de ser tomada pelo 
programador. Dividir programas grandes em pequenas partes modulares era demorado e ma- 
çante. Não demorou muito para que alguém pensasse em uma maneira de transferir o trabalho 
todo para o computador. 

O método inventado se tornou conhecido como memória virtual (Fotheringham, 
1961). A idéia básica por trás da memória virtual é que o tamanho combinado do programa, 
dos dados e da pilha pode exceder a quantidade de memória física disponível para eles. O 
sistema operacional mantém na memória principal as partes do programa correntemente em 
uso e o restante no disco. Por exemplo, um programa de 512 MB pode ser executado em 
uma máquina de 256 MB escolhendo-se cuidadosamente quais 256 MB serão mantidos na 
memória a cada instante, com partes do programa sendo alternadas entre o disco e a memória, 
conforme for necessário. 

A memória virtual também funciona em um sistema de multiprogramação, com dados e 
partes de vários programas mantidos simultaneamente em memória. Enquanto um programa 
está esperando que uma parte dele seja transferida do disco para a memória, ele está bloquea- 
do em uma operação de E/S e não pode ser executado; portanto, a CPU pode ser concedida a 
outro processo, da mesma maneira que em qualquer outro sistema de multiprogramação. 
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4.3.1 Paginação 
A maioria dos sistemas de memória virtual usa uma técnica chamada paginação, que vamos 
descrever agora. Em qualquer computador, existe um conjunto de endereços de memória que 
os programas podem gerar. Quando um programa usa uma instrução como 


MOV REG,1000 


ele faz isso para copiar o conteúdo do endereço de memória 1000 em REG (ou vice-versa, 
dependendo do computador). Os endereços podem ser gerados usando-se indexação, registra- 
dores de base, registradores de segmento e outras maneiras. 


A CPU envia endereços 
CPU virtuais para a MMU 


(propriamente dita) 


(chip) A MMU envia = Controladora 
endereços Memória de disco 
físicos para 
a memória 


Barramento 


Unidade de gerenciamento 
de memória (MMU) 


Figura 4-7 A posição e a função da MMU (Memory Management Unit). Aqui, a MMU é 
mostrada como uma parte integrante do chip da CPU (processador), pois hoje em dia nor- 
malmente é assim. Entretanto, logicamente ela poderia ser um chip separado e, no passado, 
era mesmo. 


Esses endereços gerados pelo programa são chamados de endereços virtuais e formam 
o espaço de endereçamento virtual. Nos computadores sem memória virtual, o endereço 
virtual é posto diretamente no barramento de memória e faz com que a palavra de memória 
física com o mesmo endereço venha a ser lida ou escrita. Quando é usada memória virtual, 
os endereços virtuais não vão diretamente para o barramento da memória. Em vez disso, eles 
vão para uma MMU (Memory Management Unit — unidade de gerenciamento de memória) 
que faz o mapeamento dos endereços virtuais em endereços físicos de memória, como ilus- 
trado na Figura 4-7. 

Um exemplo muito simples do funcionamento desse mapeamento aparece na Figura 
4-8. Nesse exemplo, temos um computador que pode gerar endereços de 16 bits, de O a 64K. 
Esses são os endereços virtuais. Esse computador, entretanto, tem apenas 32 KB de memória 
física; portanto, embora programas de 64 KB possam ser escritos, eles não podem ser carre- 
gados em sua totalidade na memória e executar. Contudo, uma cópia completa da imagem 
de memória de um programa, até 64 KB, deve estar presente no disco para que essas partes 
possam ser trazidas conforme for necessário. 

O espaço de endereçamento virtual é dividido em unidades chamadas páginas. As unida- 
des correspondentes na memória física são chamadas de quadros de página. As páginas e os 
quadros de página têm sempre o mesmo tamanho. Nesse exemplo, eles têm 4 KB, mas tamanhos 
de página de 512 bytes a 1 MB são usados em sistemas reais. Com 64 KB de espaço de endere- 
çamento virtual e 32 KB de memória física, temos 16 páginas virtuais e 8 quadros de página. As 
transferências entre a memória RAM e o disco são sempre feitas em unidades de uma página. 
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Quando o programa tenta acessar o endereço 0, por exemplo, usando a instrução 
MOV REG,0 


o endereço virtual O é enviado para a MMU. A MMU vê que esse endereço virtual cai na 
página O (de O a 4095), a qual, de acordo com seu mapeamento, é o quadro de página 2 
(de 8192 a 12287). Assim, ela transforma o endereço virtual O no endereço físico 8192 e o 
coloca no barramento. A memória não sabe absolutamente nada sobre a MMU e vê apenas 
uma requisição para ler ou escrever no endereço 8192, a qual executa. Assim, a MMU efe- 
tivamente fez o mapeamento de todos os endereços virtuais entre O e 4095 nos endereços 
físicos de 8192 a 12287. 
Analogamente, uma instrução 


MOV REG,8192 
é efetivamente transformada em 
MOV REG,24576 


pois o endereço virtual 8192 está na página virtual 2 e essa página é mapeada no quadro de 
página 6 (endereços físicos de 24576 a 28671). Como um terceiro exemplo, o endereço vir- 
tual 20500 está a 20 bytes a partir do início da página virtual 5 (endereços virtuais de 20480 
a 24575) e é mapeado no endereço físico 12288 + 20 = 12308. 


Espaço de 
endereçamento 
virtual 
60K-64K 
56K-60K 
52K-56K 
48K-52K 
44K-48K 
40K-44K 
36k-40K e 
32K-36K memória 
28K-32K 28K-32K 
24K-28K 24K-28K 
20K-24K 20K-24K 
16K-20K 16K-20K 
12K-16K 12K-16K 
8K-12K 8K-12K 
4K-8K 4K-8K 
OK-4K 0K-4K 


Quadro de página 
Figura 4-8 O relacionamento entre endereços virtuais e endereços físicos de memória é 


dado pela tabela de páginas. 


Por si só, essa capacidade de fazer o mapeamento das 16 páginas virtuais em qualquer 
um dos oito quadros de página, configurando apropriadamente o mapa da MMU, não resolve 
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o problema de o espaço de endereçamento virtual ser maior do que a memória física. Como 
temos apenas oito quadros de página, apenas oito páginas virtuais da Figura 4-8 são mape- 
adas na memória física. As outras, mostradas como um X na figura, não são mapeadas. No 
hardware real, um bit presente/ausente monitora quais páginas estão fisicamente presentes 
na memória. 

O que acontece se o programa tenta usar uma página não mapeada, por exemplo, utili- 
zando a instrução 


MOV REG,32780 


que é o byte 12 dentro da página virtual 8 (começando em 32768)? A MMU nota que a página 
não está mapeada (indicada por um X na figura) e faz a CPU interromper o sistema opera- 
cional. Essa interrupção é chamada de falta de página. O sistema operacional escolhe um 
quadro de página pouco usado e armazena seu conteúdo de volta no disco. Em seguida, busca 
a página que acabou de ser referenciada e a carrega no quadro de página que acabou de ser 
liberado, altera o mapa e reinicia a instrução interrompida. 

Por exemplo, se o sistema operacional decidisse retirar o quadro de página 1, ele car- 
regaria a página virtual 8 no endereço físico 4K e faria duas alterações no mapa da MMU. 
Primeiramente, ele marcaria a entrada da página virtual 1 como não mapeada, para impedir 
quaisquer futuros acessos aos endereços virtuais entre 4K e 8K. Então, substituíria o X na 
entrada da página virtual 8 por 1, para que, quando a instrução interrompida fosse executada 
novamente, fizesse o mapeamento do endereço virtual 32780 no endereço físico 4108. 

Agora, vamos olhar dentro da MMU para vermos como ela funciona e porque optamos 
por usar um tamanho de página que é uma potência de 2. Na Figura 4-9, vemos um exemplo 
de endereço virtual, 8196 (0010000000000100, em binário), sendo mapeado com o mapa 
da MMU da Figura 4-8. O endereço virtual de 16 bits recebido é dividido em um número de 
página de 4 bits e um deslocamento de 12 bits. Com 4 bits para o número de página, podemos 
ter 16 páginas, e com 12 bits para o deslocamento, podemos endereçar todos os 4096 bytes 
dentro de uma página. 

O número de página é usado como índice na tabela de páginas, gerando o número 
do quadro de página correspondente a essa página virtual. Se o bit presente/ausente é O, é 
causada uma interrupção no sistema operacional. Se o bit é 1, o número do quadro de página 
encontrado na tabela de páginas é copiado nos 3 bits de ordem superior do registrador de 
endereço de saída, junto com o deslocamento de 12 bits, que é copiado sem modificação do 
endereço virtual recebido. Juntos, eles formam um endereço físico de 15 bits. Então, o regis- 
trador de saída é colocado no barramento da memória como o endereço de memória físico. 


Tabelas de página 


No caso mais simples, o mapeamento de endereços virtuais em endereços físicos é como aca- 
bamos de descrever. O endereço virtual é dividido em um número de página virtual (bits de 
ordem superior) e um deslocamento (bits de ordem inferior). Por exemplo, com um endereço 
de 16 bits e um tamanho de página de 4 KB, os 4 bits superiores poderiam especificar uma 
das 16 páginas virtuais e os 12 bits inferiores especificariam então o deslocamento de byte 
(de O a 4095) dentro da página selecionada. Entretanto, também é possível uma divisão com 
3, 5 ou algum outro número de bits para a página. Diferentes divisões implicam em diferentes 
tamanhos de página. 

O número de página virtual é usado como índice na tabela de páginas para localizar a 
entrada dessa página virtual. A partir da entrada na tabela de páginas, é encontrado o número 
do quadro de página (se houver). O número do quadro de página é anexado à extremidade de 
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Figura 4-9 O funcionamento interno da MMU com 16 páginas de 4 KB. 


ordem superior do deslocamento, substituindo o número de página virtual, para formar um 
endereço físico que pode ser enviado para a memória. 

O objetivo da tabela de páginas é fazer o mapeamento de páginas virtuais em quadros 
de página. Matematicamente falando, a tabela de páginas é uma função, com o número de pá- 
gina virtual como argumento e o número de quadro físico como resultado. Usando o resultado 
dessa função, o campo da página virtual em um endereço virtual pode ser substituído por um 
campo de quadro de página, formando assim um endereço de memória físico. 

Apesar dessa descrição simples, dois problemas importantes devem ser enfrentados: 


1. A tabela de páginas pode ser extremamente grande. 


2. O mapeamento deve ser rápido. 


O primeiro ponto é conseqüência do fato de que os computadores modernos usam en- 
dereços virtuais de pelo menos 32 bits. Com, digamos, um tamanho de página de 4 KB, um 
espaço de endereçamento de 32 bits tem 1 milhão de páginas e um espaço de endereçamento 
de 64 bits tem muito mais do que você desejaria acessar. Com 1 milhão de páginas no espaço 
de endereçamento virtual, a tabela de páginas deve ter 1 milhão de entradas. E lembre-se de 
que cada processo precisa de sua própria tabela de páginas (porque possui seu próprio espaço 
de endereçamento virtual). 

O segundo ponto é uma conseqüência do fato de que o mapeamento de endereço virtual 
para físico deve ser feito a cada referência à memória. Uma instrução típica tem uma palavra 
de instrução e, freqüentemente, tem também um operando em memória. Conseqüentemente, 
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é necessário fazer uma, duas ou, às vezes, mais referências à tabela de páginas por instrução. 
Se uma instrução demora, digamos, 1 ns, a pesquisa da tabela de páginas deve ser feita em 
menos de 250 ps para que não se torne um gargalo sério. 

A necessidade de fazer um mapeamento rápido e eficiente de páginas a partir de uma 
tabela de páginas grande é um desafio na maneira como os computadores são construídos. 
Embora o problema seja mais sério nas máquinas de ponta, que precisam ser muito rápidas, 
também é um problema nas de baixo poder computacional, onde o custo e a relação preço/de- 
sempenho são críticos. Nesta seção e nas seguintes, veremos o projeto da tabela de páginas 
em detalhes e mostraremos diversas soluções de hardware que têm sido utilizadas nos com- 
putadores reais. 

O projeto mais simples (pelo menos conceitualmente) é ter uma única tabela de páginas 
composta por um conjunto de registradores em hardware bastante rápidos, com uma entrada 
para cada página virtual, indexada pelo número de página virtual, como se vê na Figura 4-9. 
Quando um processo é iniciado, o sistema operacional carrega os registradores com a tabela 
de páginas do processo, extraída de uma cópia mantida na memória principal. Durante a 
execução do processo, mais nenhuma referência de memória é necessária à tabela de páginas. 
As vantagens desse método são que ele é simples e não exige referências de memória durante 
o mapeamento. Uma desvantagem é que ele é potencialmente dispendioso (caso a tabela de 
páginas seja grande). Além disso, a necessidade de carregar a tabela de páginas inteira em 
cada troca de contexto prejudica o desempenho. 

No outro extremo, a tabela de páginas pode estar inteiramente na memória principal. 
Então, tudo que o hardware precisa é de um único registrador que aponte para o início da 
tabela de páginas em memória. Esse projeto permite que o mapa de memória seja alterado 
em uma troca de contexto, por meio da carga de um único registrador. Naturalmente, ele tem 
a desvantagem de exigir uma ou mais referências de memória para ler as entradas da tabela 
de páginas durante a execução de cada instrução. Por isso, essa estratégia raramente é usada 
em sua forma mais pura, mas a seguir estudaremos algumas variações que têm desempenho 
muito melhor. 


Tabelas de página multinível 


Para evitar o problema de ter de armazenar tabelas de página enormes na memória o tempo 
todo, muitos computadores usam uma tabela de páginas de vários níveis. Um exemplo sim- 
ples aparece na Figura 4-10. Na Figura 4-10(a), temos um endereço virtual de 32 bits parti- 
cionado em um campo PT7 de 10 bits, um campo PT2 de 10 bits e um campo Deslocamento 
de 12 bits. Como os deslocamentos são de 12 bits, as páginas têm 4 KB e existe um total de 
2” delas. 

O segredo do método da tabela de páginas multinível é não manter toda a tabela de 
página na memória o tempo todo a dividindo em subtabelas. Em particular, as tabelas que 
não são necessárias não devem ser mantidas em memória. Suponha, por exemplo, que um 
processo precise de 12 megabytes, com os 4 megabytes inferiores da memória para texto do 
programa, os 4 megabytes seguintes para dados e os 4 megabytes superiores para a pilha. 
Entre a parte superior dos dados e a parte inferior da pilha existe uma lacuna gigantesca que 
não é utilizada. 

Na Figura 4-10(b), vemos como uma tabela de páginas de dois níveis funciona nesse 
exemplo. À esquerda, temos a tabela de páginas de nível superior, com 1024 entradas, corres- 
pondentes ao campo PT7 de 10 bits. Quando um endereço virtual é apresentado para a MMU, 
ela primeiro extrai o campo PTI e usa esse valor como índice na tabela de páginas de nível 
superior. Cada uma dessas 1024 entradas representa 4M, pois o espaço de endereçamento 
virtual de 4 gigabytes (isto é, 32 bits) inteiro foi dividido em trechos de 1024 bytes. 
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A entrada localizada pela indexação na tabela de páginas de nível superior fornece o 
endereço ou o número do quadro de página de uma tabela de páginas de segundo nível. A 
entrada O da tabela de páginas de nível superior aponta para a tabela de páginas do texto do 
programa, a entrada 1 aponta para a tabela de páginas dos dados e a entrada 1023 aponta para 
a tabela de páginas da pilha. As outras entradas (sombreadas) não são usadas. Agora, o campo 
PT2 é usado como índice na tabela de páginas de segundo nível selecionada, para encontrar o 
número do quadro de página da página em si. 


Tabelas de página 
de segundo nível 


Tabela de 
páginas 
para os 4M 
superiores 
da memória 


Tabela de páginas 
de nível superior 


1023 


Bits 10 10 12 
Desloca- 


(a) 


Sano Ra o 


-NOUA 


[e] 


= o 
(b) 


Figura 4-10 (a) Um endereço de 32 bits com dois campos de tabela de páginas. (b) Tabelas 
de página de dois níveis. 


Como exemplo, considere o endereço virtual de 32 bits 0x00403004 (4.206.596 em 
decimal), que tem 12.292 bytes nos dados. Esse endereço virtual corresponde a PTI = 1, PT2 
= 2 e Deslocamento = 4. A MMU primeiro utiliza PTI para indexar na tabela de páginas de 
nível superior e obter a entrada 1, que corresponde aos endereços de 4M a 8M. Então, ela usa 
PT2 para indexar na tabela de páginas de segundo nível que acabou de encontrar e extrair a 
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entrada 3, que corresponde aos endereços de 12.288 a 16.383 dentro de seu trecho de 4M (isto 
é, os endereços absolutos de 4.206.592 a 4.210.687). Essa entrada possui o número do quadro 
de página física que contém a página virtual associada ao endereço (virtual) 0x00403004. Se 
essa página não estiver na memória, o bit presente/ausente na entrada da tabela de páginas 
será zero, causando uma exceção de falta de página. Se a página estiver na memória, o núme- 
ro do quadro de página extraído da tabela de páginas de segundo nível será combinado com o 
deslocamento (4) para construir um endereço físico. Esse endereço é colocado no barramento 
e enviado para a memória. 

O interessante a notar na Figura 4-10 é que, embora o espaço de endereçamento conte- 
nha mais de um milhão de páginas, apenas quatro tabelas de página são realmente necessá- 
rias: a tabela de nível superior e as tabelas de segundo nível para as porções de memória de 
0 a 4M, de 4M a 8M e para os 4M superiores. Os bits presente/ausente nas 1021 entradas da 
tabela de páginas de nível superior são configurados como 0, forçando uma exceção de falta 
de página se forem acessadas. Se isso ocorrer, o sistema operacional notará que o processo 
está tentando referenciar memória que não deveria e executará a ação apropriada, como en- 
viar um sinal para ele ou eliminá-lo. Nesse exemplo, escolhemos números redondos para 
os diversos tamanhos e selecionamos PTI igual a PT2, mas na prática, obviamente, outros 
valores também são possíveis. 

O sistema de tabela de páginas de dois níveis da Figura 4-10 pode ser expandido para 
três, quatro ou mais níveis. Níveis adicionais proporcionam mais flexibilidade, mas há dúvi- 
das de que a complexidade adicional além de dois níveis compense. 


Estrutura de uma entrada da tabela de páginas 


Vamos passar agora da estrutura geral da tabela de página para vermos os detalhes de uma 
única entrada sua. O layout exato de uma entrada é altamente dependente da máquina, mas o 
tipo de informação presente é praticamente o mesmo de uma máquina para outra. Na Figura 
4-11, damos um exemplo de entrada da tabela de páginas. O tamanho varia de um computa- 
dor para outro, mas 32 bits é um tamanho comum. O campo mais importante é o número do 
quadro de página. Afinal, o objetivo do mapeamento de página é localizar esse valor. Depois 
dele, temos o bit presente/ausente. Se esse bit for 1, a entrada será válida e poderá ser usada. 
Se ele for 0, a página virtual à qual a entrada pertence não está correntemente na memória. 
Acessar uma entrada da tabela de páginas com esse bit configurado como O causa uma exce- 
ção de falta de página. 


Uso de cache 
desativado Modificação Presente/ausente 


PT e f] 


Referência Proteção 


Figura 4-11 Uma entrada típica de tabela de páginas. 


O bits proteção informam quais tipos de acesso são permitidos. Na forma mais simples, 
esse campo contém 1 bit, com 0 para leitura/escrita e 1 para leitura somente. Uma organiza- 
ção mais sofisticada é ter 3 bits independentes, cada bit para ativar individualmente a leitura, 
escrita e execução da página. 
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Os bits modificação e referência monitoram a utilização da página. Quando uma página 
é escrita, o hardware ativa automaticamente o bit modificação. Esse bit é usado quando o sis- 
tema operacional decide recuperar um quadro de página. Se a página que está nele foi modifi- 
cada (isto é, está “suja”, ela deve ser reescrita no disco. Se ela não tiver sido modificada (isto 
é, está “limpa”), pode ser simplesmente abandonada, pois a cópia do disco ainda é válida. Às 
vezes, o bit é chamado de bit sujo (dirty bit), pois reflete o estado da página. 

O bit referência é ativado quando uma página é acessada, seja para leitura ou para escri- 
ta. Seu objetivo é ajudar o sistema operacional a escolher uma página para substituir quando 
ocorrer uma falta de página. As páginas que não estão sendo usadas são candidatas melhores 
do que as que estão, e esse bit desempenha uma função importante em vários algoritmos de 
substituição de página que estudaremos posteriormente neste capítulo. 

Finalmente, o último bit permite que o uso de cache seja desativado para a página. Esse 
recurso é importante para páginas que são mapeadas em registradores de dispositivo, em 
vez da memória. Se o sistema operacional estiver executando um laço, esperando que algum 
dispositivo de E/S responda a um comando que acabou de receber, é fundamental que o har- 
dware continue buscando a palavra do dispositivo e não utilize uma cópia antiga armazenada 
na cache. Com esse bit, a operação da cache pode ser desligada. As máquinas que têm um 
espaço de E/S separado e não utilizam E/S mapeada na memória não precisam desse bit. 

Note que o endereço do disco usado para conter a página quando ela não está na memó- 
ria não faz parte da tabela de páginas. O motivo é simples. A tabela de páginas contém apenas 
as informações que o hardware precisa para transformar um endereço virtual em endereço 
físico. As informações que o sistema operacional precisa para tratar as exceções de falta de 
página são mantidas em estruturas de dados internas do próprio sistema operacional. O har- 
dware não precisa delas. 


Translation Lookaside Buffers (TLB) 


Na maioria dos esquemas de paginação, as tabelas de página são mantidas em memória, 
devido ao seu tamanho grande. Potencialmente, esse projeto tem um impacto enorme sobre 
o desempenho. Considere, por exemplo, uma instrução que copia o valor de um registrador 
para outro. Na ausência de paginação, essa instrução faz apenas uma referência de memória, 
para buscar a instrução. Com paginação, referências adicionais de memória serão necessárias 
para acessar a tabela de páginas. Como a velocidade de execução geralmente é limitada pela 
velocidade com que a CPU pode obter instruções e dados da memória, a necessidade de fazer 
duas referências à tabela de páginas por referência de memória reduz o desempenho em 2/3. 
Sob essas condições, ninguém a utilizaria. 

Os projetistas de computador sabem desse problema há anos e apresentaram uma so- 
lução. A solução é baseada na observação de que a maioria dos programas tende a fazer um 
grande número de referências para um pequeno número de páginas e não o contrário. Assim, 
apenas uma pequena fração das entradas da tabela de páginas é lida intensamente; as restan- 
tes são muito pouco utilizadas. Esse é um exemplo de localidade de referência, um conceito 
ao qual voltaremos em uma seção posterior. 

A solução imaginada foi equipar os computadores com um pequeno dispositivo de har- 
dware para mapear endereços virtuais em endereços físicos rapidamente, sem passar pela 
tabela de páginas. O dispositivo, chamado de TLB (Translation Lookaside Buffer), ou, às 
vezes, de memória associativa, está ilustrado na Figura 4-12. Normalmente, ele fica dentro 
da MMU e consiste em um pequeno número de entradas, oito neste exemplo, mas raramente 
mais do que 64. Cada entrada contém informações sobre uma página, incluindo o número 
de página virtual, um bit que é ativado quando a página é modificada, o código de proteção 
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(permissões para ler/escrever/executar) e o quadro físico de página no qual a página está 
localizada. Esses campos têm uma correspondência biunívoca com os campos da tabela de 
páginas. Outro bit indica se a entrada é válida (isto é, está em uso) ou não. 


Válida | Página virtual | Modificada | Proteção | Quadro de página 
1 140 1 RW 31 
1 20 0 RX 38 
1 130 1 RW 29 
1 129 1 RW 62 
1 19 0 RX 50 
1 21 0 RX 45 
1 860 1 RW 14 
1 861 1 RW 75 


Figura 4-12 Um TLB para acelerar a paginação. 


Um exemplo que poderia gerar o TLB da Figura 4-12 é um processo em um laço que 
abrange as páginas virtuais 19, 20 e 21, de modo que essas entradas de TLB têm permissões 
de proteção para ler e executar. Os principais dados correntemente em uso (digamos, um ar- 
ray que esteja sendo acessado) estão nas páginas 129 e 130. A página 140 contém os índices 
usados nos cálculos do array. Finalmente, a pilha está nas páginas 860 e 861. 

Vamos ver agora como o TLB funciona. Quando um endereço virtual é apresentado 
para a MMU para transformação, primeiro o hardware verifica se seu número de página 
virtual está presente no TLB, comparando-o simultaneamente com todas as entradas (isto é, 
em paralelo). Se for encontrada uma correspondência válida e o acesso não violar os bits de 
proteção, o quadro de página será extraído diretamente do TLB, sem passar pela tabela de 
páginas. Se o número de página virtual estiver presente no TLB, mas a instrução estiver ten- 
tando escrever em uma página somente de leitura, será gerado um erro de proteção, da mesma 
maneira que aconteceria na própria tabela de páginas. 

O caso interessante é o que acontece quando o número de página virtual não está no 
TLB. A MMU detecta a ausência e faz uma pesquisa na tabela de páginas normal (em me- 
mória). Então, ela substitui uma das entradas do TLB pela entrada da tabela de páginas que 
acabou de ser pesquisada. Assim, se essa página for usada novamente em breve, a segunda 
vez resultará em um número de página virtual encontrado e não em uma falta. Quando uma 
entrada é retirado do TLB, o bit modificação é copiado de volta na entrada da tabela de pá- 
ginas, na memória. Os outros valores já estão lá. Quando o TLB é carregado da tabela de 
páginas, todos os campos são extraídos da memória. 


Gerenciamento do TLB por software 


Até agora, assumimos que cada máquina que possui memória virtual baseada em paginação 
possui tabelas de página reconhecidas pelo hardware, além de um TLB. Neste projeto, o ge- 
renciamento do TLB e o tratamento de erros de TLB são feitos inteiramente pelo hardware 
da MMU. As interrupções no sistema operacional só ocorrem quando uma página não está 
na memória. 

No passado, essa suposição era verdadeira. Entretanto, muitas máquinas RISC moder- 
nas, incluindo SPARC, MIPS, HP PA e PowerPC, fazem praticamente todo esse gerencia- 
mento de páginas em software. Nessas máquinas, as entradas do TLB são carregadas expli- 
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citamente pelo sistema operacional. Quando ocorre uma falta na TLB (TLB miss), em vez da 
MMU ir simplesmente até as tabelas de página para localizar e buscar a referência de página 
desejada, ela apenas gera uma exceção de falta na TLB e joga o problema para o sistema 
operacional. O sistema operacional deve encontrar a página, remover uma entrada do TLB, 
inserir uma nova e reiniciar a instrução que falhou. E, é claro, tudo isso deve ser feito com 
poucas instruções, pois as faltas na TLB ocorrem muito mais frequentemente do que as faltas 
de página. 

Surpreendentemente, se o TLB for razoavelmente grande (digamos, com 64 entradas) 
para reduzir a taxa de perdas, o gerenciamento por software do TLB se mostrará aceitavel- 
mente eficiente. A principal vantagem dessa abordagem é ter uma MMU muito mais simples, 
que libera uma área considerável no chip da CPU para caches e outros recursos que podem 
melhorar o desempenho. O gerenciamento do TLB por software está discutido em Uhlig et 
al. (1994). 

Várias estratégias foram desenvolvidas para melhorar o desempenho em máquinas que 
fazem gerenciamento do TLB por software. Uma delas ataca a redução da quantidade de 
faltas na TLB e do custo para tratar cada uma delas quando ocorrem (Bala et al., 1994). Para 
reduzir as faltas na TLB, às vezes o sistema operacional pode usar sua intuição para descobrir 
quais páginas provavelmente serão usadas em seguida e carregar previamente as entradas 
para elas no TLB. Por exemplo, quando um processo cliente envia uma mensagem para um 
processo servidor na mesma máquina, é muito provável que o servidor tenha que executar 
em breve. Sabendo disso, enquanto processa a interrupção para executar a operação send, o 
sistema também pode verificar onde estão as páginas de código, dados e pilha do servidor e 
fazer seu mapeamento antes que elas possam causar faltas na TLB. 

A maneira normal de processar uma falta na TLB, seja no hardware ou no software, 
é ir até a tabela de páginas e executar as operações de indexação para localizar a página 
referenciada. O problema de fazer essa pesquisa no software é que as páginas que contêm a 
tabela de páginas podem não estar no TLB, o que causará faltas adicionais na TLB durante o 
processamento. Esses faltas podem ser reduzidas mantendo-se uma cache de software grande 
(por exemplo, de 4 KB ou mais) de entradas de TLB em um local fixo, cuja página seja sem- 
pre mantida no TLB. Verificando primeiro a cache de software, o sistema operacional pode 
reduzir substancialmente o número de faltas na TLB. 


Tabela de páginas invertida 


As tabelas de página tradicionais do tipo descrito até aqui exigem uma única entrada por pá- 
gina virtual, pois são indexadas pelo número de página virtual. Se o espaço de endereçamento 
consiste em 2” bytes, com 4096 bytes por página, então são necessárias mais de 1 milhão de 
entradas na tabela de páginas. No mínimo, a tabela de páginas terá pelo menos 4 megabytes. 
Em sistemas grandes, esse tamanho provavelmente é viável. 

Entretanto, à medida que os computadores de 64 bits se tornam mais comuns, a situação 
muda drasticamente. Se agora o espaço de endereçamento é de or bytes, com páginas de 4 
KB, precisamos de uma tabela de páginas com 2” entradas. Se cada entrada tem 8 bytes, a 
tabela tem mais de 30 milhões de gigabytes. Ocupar 30 milhões de gigabytes apenas para a 
tabela de páginas não é viável, nem agora nem nos próximos anos, se é que algum dia será. 
Conseqiientemente, é necessária uma solução diferente para espaços de endereçamentos vir- 
tuais paginados de 64 bits. 

Uma solução para isso é a tabela de páginas invertida. Nesse projeto, há uma entrada 
por quadro de página na memória real, em vez de uma entrada por página de espaço de en- 
dereçamento virtual. Por exemplo, com endereços virtuais de 64 bits, uma página de 4 KB e 
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256 MB de memória RAM, uma tabela de páginas invertida exige apenas 65.536 entradas. A 
entrada monitora qual par (processo, página virtual) está localizado no quadro de página. 

Embora as tabelas de página invertidas economizem grandes quantidades de espaço em 
memória, pelo menos quando o espaço de endereçamento virtual é muito maior do que a me- 
mória física, elas têm um sério inconveniente: o mapeamento de endereço virtual para físico 
se torna muito mais difícil. Quando o processo n referencia a página virtual p, o hardware 
não pode mais encontrar a página física usando p como índice na tabela de páginas. Em vez 
disso, ele precisa pesquisar a tabela de páginas invertida inteira em busca de uma entrada (n, 
p). Além disso, essa pesquisa deve ser feita a cada referência de memória e não apenas nas 
faltas de página. Pesquisar uma tabela de 64K a cada referência de memória definitivamente 
não é uma boa maneira de tornar sua máquina rápida. 

A saída para esse dilema é usar o TLB. Se o TLB puder conter todas as páginas freqüen- 
temente mais utilizadas, a transformação poderá acontecer com a mesma rapidez das tabelas 
de página normais. Contudo, no caso de uma falta na TLB, a tabela de páginas invertida pre- 
cisará ser pesquisada no software. Uma maneira viável de fazer essa pesquisa é ter uma tabela 
hash calculada com base no endereço virtual. Todas as páginas virtuais correntemente na 
memória que tenham o mesmo valor de hash são encadeadas, como se vê na Figura 4-13. Se 
a tabela de hash tiver tantas entradas quanto a máquina tiver páginas físicas, o encadeamento 
médio terá apenas uma entrada, acelerando bastante o mapeamento. Uma vez que o número 
do quadro de página tiver sido encontrado, o novo par (virtual, físico) será inserido no TLB e 
a instrução que provocou a falta na TLB poderá ser reiniciada. 

As tabelas de página invertidas são correntemente usadas em estações de trabalho IBM, 
Sun e Hewlett-Packard e serão mais comuns à medida que as máquinas de 64 bits se tornarem 
mais difundidas. As tabelas de página invertidas são fundamentais nessas máquinas. Outras 
estratégias para o tratamento de espaço de endereçamento virtual grande podem ser encon- 
tradas em Huck e Hays (1993), em Talluri e Hill (1994) e em Talluri et al. (1995). Algumas 
questões de hardware na implementação da memória virtual são discutidas por Jacob e Mud- 
ge (1998). 


Tabela de páginas 
tradicional com uma 
entrada para cada 
uma das 252 páginas 
252 -1 E 
A memória física 
de 256 MB tem 
216 quadros de 
página de 4 KB Tabela hash 


216-1 E 216-1 E II 


N l 


Indexada Indexada 
pela página pelo hash da Página Quadro 
virtual página virtual virtual de página 


Figura 4-13 Comparação de uma tabela de páginas tradicional com uma tabela de páginas 
invertida. 


370 


SISTEMAS OPERACIONAIS 


4.4 ALGORITMOS DE SUBSTITUIÇÃO DE PÁGINA 


4.4.1 


Quando ocorre uma falta de página, o sistema operacional precisa escolher uma página para 
remover da memória, para liberar espaço para a página que precisa ser trazida. Se a página 
a ser removida tiver sido modificada enquanto estava na memória, ela deverá ser escrita no 
disco para atualizar sua cópia no disco. Entretanto, se a página não foi alterada (por exemplo, 
ela contém o código do programa), a cópia do disco já está atualizada; portanto, nenhuma 
escrita é necessária. A página a ser lida simplesmente sobrescreve a página que está sendo 
substituída. 

Embora seja possível a cada falta de página escolher uma página aleatória para ser 
substituída, o desempenho do sistema será muito melhor se for escolhida uma página não 
muito utilizada. Se for removida uma página muito utilizada, ela provavelmente terá de ser 
trazida de volta rapidamente, resultando em sobrecarga extra. Muito trabalho foi feito sobre o 
assunto dos algoritmos de substituição de página, tanto teórico como experimental. A seguir, 
descreveremos alguns dos algoritmos mais importantes. 

Vale notar que o problema da “substituição de página” também ocorre em outras áreas 
de projeto de computador. Por exemplo, a maioria dos computadores tem uma ou mais caches 
de memória consistindo em blocos de memória de 32 bytes ou de 64 bytes recentemente 
usados. Quando a cache está cheia, algum bloco precisa ser escolhido para remoção. Esse 
problema é precisamente igual ao da substituição de página, exceto que em uma escala de 
tempo mais curta (isso precisa ser feito em alguns nanossegundos e não em milissegundos, 
como acontece com a substituição de página). O motivo da escala de tempo mais curta é que 
as faltas de blocos na cache são escritas a partir da memória principal, que não tem tempo de 
busca nem latência rotacional. 

Um segundo exemplo é um navegador web. O navegador mantém cópias das páginas 
web acessadas anteriormente em uma cache no disco. Normalmente, o tamanho máximo da 
cache é fixado antecipadamente, de modo que é provável que ela fique cheia, caso o navega- 
dor seja muito usado. Quando uma página web é referenciada, é feita uma verificação para 
ver se há uma cópia na cache e, se houver, se a página web é mais recente. Se a cópia colo- 
cada na cache estiver atualizada, ela será usada; caso contrário, uma cópia nova será buscada 
na web. Se a página não estiver na cache, ou se uma versão mais recente estiver disponível, 
ela será carregada por download. Se for uma cópia mais recente de uma página colocada na 
cache, ela substituirá a que está na cache. Quando a cache está cheia, uma decisão precisa ser 
tomada para substituir alguma outra página, no caso de uma página nova ou de uma página 
que seja maior do que uma versão mais antiga. As considerações são semelhantes às das pá- 
ginas de memória virtual, exceto quanto ao fato de que as páginas web nunca são modificadas 
na cache e, assim, nunca são escritas de volta no servidor web. Em um sistema de memória 
virtual, as páginas na memória principal podem ser limpas ou sujas. 


O algoritmo de substituição de página ótimo 


O melhor algoritmo de substituição de página possível é fácil de descrever, mas impossível de 
implementar. Acompanhe o raciocínio. No momento em que ocorre uma falta de página, um 
conjunto de páginas está na memória. Uma dessas páginas será referenciada na próxima instru- 
ção (a página que contém essa instrução). Eventualmente, as outras páginas só serão referencia- 
das daqui a 10, 100 ou talvez 1000 instruções. Cada página pode ser rotulada com o número de 
instruções que serão executadas antes que a página seja referenciada pela primeira vez. 

O algoritmo de página ótimo diz simplesmente que a página com o rótulo mais alto 
deve ser removida. Se uma página não vai ser usada por 8 milhões de instruções e outra não 
vai ser usada por 6 milhões de instruções, remover a primeira postergará por mais tempo pos- 
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sível a falta de página que fará buscá-la de volta. Os computadores, assim como as pessoas, 
tentam adiar os eventos desagradáveis o máximo que podem. 

O único problema desse algoritmo é que ele não pode ser realizado. No momento da 
falta de página, o sistema operacional não tem como saber quando cada uma das páginas será 
referenciada no futuro. (Vimos uma situação semelhante anteriormente, no algoritmo de es- 
calonamento da tarefa mais curta primeiro — como o sistema pode saber qual é a tarefa mais 
curta?) Apesar disso, executando um programa em um simulador e monitorando todas as 
referências de página, é possível implementar a substituição de página ótima na segunda exe- 
cução, usando as informações de referência de página reunidas durante a primeira execução. 

Dessa forma é possível comparar o desempenho de algoritmos realizáveis com o me- 
lhor possível. Se um sistema operacional alcançar um desempenho de, digamos, apenas 1% 
pior do que o algoritmo ótimo, o esforço gasto em procurar um algoritmo melhor resultará em 
uma melhoria de 1%, no máximo. 

Para evitar qualquer possível confusão, deve ficar claro que esse registro de referência 
de página refere-se apenas ao programa que acabou de ser medido e, além disso, com apenas 
uma entrada específica. Assim, o algoritmo de substituição de página derivado dele é especí- 
fico para esse programa e para esses dados de entrada. Embora esse método seja útil para ava- 
liar algoritmos de substituição de página, ele é inútil em sistemas reais. A seguir, estudaremos 
algoritmos que são úteis em sistemas reais. 


O algoritmo de substituição de página não usada recentemente 


Para permitir que o sistema operacional reúna estatísticas úteis a respeito de quais páginas 
estão sendo utilizadas e quais não, a maioria dos computadores com memória virtual tem dois 
bits de status associados a cada página. O bit R é ativado quando a página é referenciada (lida 
ou escrita). O bit M é ativado quando a página é escrita (isto é, modificada). Os bits estão con- 
tidos em cada entrada da tabela de páginas, como se vê na Figura 4-11. É importante perceber 
que esses bits devem ser atualizados a cada referência de memória; portanto, é fundamental 
que eles sejam ativados pelo hardware. Uma vez que um bit tiver sido configurado como 1, 
ele continuará sendo 1 até que o sistema operacional o recoloque em O por software. 

Se o hardware não tiver esses bits, eles podem ser simulados, como segue. Quando 
um processo é iniciado, todas as suas entradas da tabela de páginas são marcadas como não 
presentes na memória. Assim que uma página for referenciada, ocorrerá uma falta de página. 
Então, o sistema operacional ativa o bit R (em suas tabelas internas), altera a entrada da tabela 
de páginas para apontar para a página correta, com modo READ ONLY, e reinicia a instru- 
ção. Assim, subsequentemente, quando for feita uma escrita na página será gerado um erro de 
proteção na página e o tratamento dessa exceção permitirá que o sistema operacional ative o 
bit M e altere o modo da página para READ/WRITE. 

Os bits R e M podem ser usados para construir um algoritmo de paginação simples, 
como segue. Quando um processo é iniciado, esses dois bits de todas as suas páginas são 
configurados como 0 pelo sistema operacional. Periodicamente (por exemplo, em cada inter- 
rupção de relógio), o bit R é zerado, para distinguir as páginas que não foram referenciadas 
recentemente das que foram. 

Quando ocorre uma falta de página, o sistema operacional inspeciona todas as páginas e 
as divide em quatro categorias, baseadas nos valores correntes de seus bits Re M: 


Classe 0: não referenciada, não modificada. 
Classe 1: não referenciada, modificada. 
Classe 2: referenciada, não modificada. 
Classe 3: referenciada, modificada. 
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Embora, à primeira vista, as páginas de classe 1 pareçam impossíveis, elas ocorrem 
quando uma página de classe 3 tem seu bit R zerado por uma interrupção de relógio. As 
interrupções de relógio não zeram o bit M porque essa informação é necessária para saber 
se a página precisa ser reescrita no disco ou não. Zerar R, mas não M, leva a uma página de 
classe 1. 

O algoritmo NRU (Not Recently Used — não utilizada recentemente) remove aleatoria- 
mente uma página da classe não-vazia de numeração mais baixa. Está implícito nesse algorit- 
mo o fato de que é melhor remover uma página modificada que não foi referenciada em pelo 
menos um tique de relógio (normalmente 20 ms) do que uma página limpa que está sendo 
muito utilizada. O principal atrativo do algoritmo NRU é que ele é fácil de entender, sua im- 
plementação é moderadamente eficiente e fornece um desempenho que, embora certamente 
não seja ótimo, pode ser adequado. 


O algoritmo de substituição de página FIFO 
(primeira a entrar, primeira a sair) 


Outro algoritmo de paginação de baixa sobrecarga é o FIFO (First-In, First-Out — primeira 
a entrar, primeira a sair). Para ilustrar seu funcionamento, considere um supermercado com 
prateleiras suficientes para exibir exatamente k produtos diferentes. Um dia, uma empresa 
introduz um novo alimento prático — um iogurte orgânico, congelado e seco, de preparo ins- 
tantâneo, que pode ser reconstituído em um forno de microondas. O produto é um sucesso 
imediato; portanto, nosso supermercado limitado em espaço precisa livrar-se de um produto 
antigo para armazenar o novo. 

Uma possibilidade é localizar o produto que o supermercado armazena há mais tempo 
(isto é, algo que começou a comercializar 120 anos atrás) e desfazer-se dele com base no fato 
de que ninguém mais está interessado. Na verdade, o supermercado mantém uma lista enca- 
deada de todos os produtos que vende atualmente, na ordem que eles foram introduzidos. O 
produto novo entra no fim da lista; o que está no início da lista é eliminado. 

Como um algoritmo de substituição de página, a mesma idéia pode ser aplicada. O 
sistema operacional mantém uma lista de todas as páginas correntemente na memória, com a 
página que está no início da lista sendo a mais antiga e a página que está no fim, sendo a que 
chegou mais recentemente. No caso de uma falta de página, a página que está no início da 
lista é removida e a nova página é adicionada no final. Quando aplicado a estoques, o algorit- 
mo FIFO poderia remover cera para bigode, mas também poderia remover farinha de trigo, 
sal ou manteiga. Quando aplicado aos computadores, surge o mesmo problema. Por isso, o 
algoritmo FIFO raramente é usado em sua forma pura. 


O algoritmo de substituição de página segunda chance 


Uma modificação simples no algoritmo FIFO, que evita o problema de jogar fora uma página 
muito utilizada, é inspecionar o bit R da página mais antiga. Se ele for 0, a página é antiga e 
não utilizada; portanto, é substituída imediatamente. Se o bit R é 1, o bit é zerado, a página 
é colocada no final da lista de páginas e seu tempo de carga é atualizado como se ela tivesse 
acabado de chegar na memória. Então, a pesquisa continua. 

O funcionamento desse algoritmo, chamado de segunda chance, está mostrado na Fi- 
gura 4-14. Na Figura 4-14(a), vemos as páginas de A até H mantidas em uma lista encadeada 
e ordenada pelo tempo que foram carregadas na memória. 

Suponha que ocorra uma falta de página no instante de tempo 20. A página mais antiga 
é A, que chegou no instante de tempo 0, quando o processo começou. Se A tem o bit R zerado, 
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ela é retirada da memória, ou sendo escrita no disco (se ela for suja) ou apenas abandonada 
(se for limpa). Por outro lado, se o bit R estiver ativo, A será colocada no final da lista e seu 
“tempo de carga” será reconfigurado com o tempo corrente (20). O bit R também é zerado. A 
procura por uma página continua com B. 

O que o algoritmo da segunda chance está fazendo é procurando uma página antiga 
que não tenha sido referenciada no intervalo de relógio anterior. Se todas as páginas tiverem 
sido referenciadas, o algoritmo da segunda chance degenerará para o algoritmo FIFO puro. 
Especificamente, imagine que todas as páginas na Figura 4-14(a) tenham seus bits R ativos. 
Uma por uma, o sistema operacional move as páginas para o final da lista, zerando o bit R 
sempre que anexa uma página no fim da lista. Finalmente, ele volta para a página 4, que 
agora tem seu bit R zerado. Nesse ponto, 4 é a página a ser substituída. Assim, o algoritmo 
sempre termina. 


Página carregada ago 
NO 7 12 15 
A] E E e| a 


(a) 


Página carregada 
Pea mais recentemente 


A é tratada como 
Dead uma página carregada 


14 
HoHo HEH HeH Hap seriene 


(b) 


Figura 4-14 Funcionamento do algoritmo da segunda chance. (a) Páginas classificadas na 
ordem FIFO. (b) Lista de páginas se ocorre uma falta de página no tempo 20 e A tem seu bit 
R ativo. Os números acima das páginas são seus instantes de tempo de carga. 


O algoritmo do relógio para substituição de página 


Embora o algoritmo da segunda chance seja razoável, ele é desnecessariamente ineficiente, 
pois está constantemente movendo páginas em sua lista. Uma estratégia melhor é manter to- 
dos os quadros de página em uma lista circular na forma de um relógio, como se vê na Figura 
4-15. Um ponteiro aponta para a página mais antiga. 


Quando ocorre uma falta de página, 
a página para a qual o ponteiro 
[5] está apontando é inspecionada. 


A ação adotada depende do bit R: 
R = 0: substitui a página 

E 

[+] [E] 

H| F| 


R = 1: Zera R e avança o ponteiro 
Figura 4-15 O algoritmo do relógio para substituição de página. 
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Quando ocorre uma falta de página, a página que está sendo apontada pelo ponteiro é 
inspecionada. Se seu bit R for 0, a página será substituída, a nova página será inserida no re- 
lógio em seu lugar e o ponteiro avançará uma posição. Se R for 1, ele será zerado e o ponteiro 
avançará para a próxima página. Esse processo se repete até que seja encontrada uma página 
com R = 0. Não é de surpreender que esse algoritmo seja chamado do relógio. Ele difere do 
algoritmo da segunda chance apenas na implementação e não na página selecionada. 


O algoritmo de substituição de página LRU 
(menos recentemente utilizada) 


Uma boa aproximação do algoritmo ótimo é baseada na observação de que as páginas que fo- 
ram muito utilizadas nas últimas instruções provavelmente continuarão a ser muito usadas nas 
seguintes. Inversamente, as páginas que não foram utilizadas por muito tempo provavelmente 
continuarão sem uso por mais tempo. Essa idéia sugere um algoritmo realizável: quando ocor- 
rer uma falta de página, descartar a página que não foi utilizada por mais tempo. Essa estraté- 
gia é chamada de paginação LRU (Least Recently Used — menos recentemente utilizada). 

Embora o algoritmo LRU seja realizável teoricamente, ele não é computacionalmente 
barato. Para implementar o algoritmo LRU completamente, é necessário manter uma lista 
encadeada de todas as páginas na memória, com a página mais recentemente usada no início 
e a página menos recentemente usada no final. A dificuldade é que a lista deve ser atualizada 
a cada referência de memória. Encontrar uma página na lista, excluí-la e depois movê-la para 
o início da lista é uma operação muito demorada, mesmo em hardware (supondo que esse 
hardware possa ser construído). 

Entretanto, existem outras maneiras de implementar o algoritmo LRU com auxílio de 
hardware específico. Vamos considerar a maneira mais simples primeiro. Esse método exige 
equipar o hardware com um contador de 64 bits, C, que é incrementado automaticamente 
após cada instrução. Além disso, cada entrada da tabela de páginas também deve ter um 
campo grande o bastante para conter o contador. Após cada referência de memória, o valor 
corrente de C é armazenado na entrada da tabela de páginas da página que acabou de ser 
referenciada. Quando ocorre uma falta de página, o sistema operacional examina todos os 
contadores na tabela de páginas para localizar o menor deles. Essa página é a menos recen- 
temente utilizada. 

Agora, vamos ver um segundo algoritmo LRU em hardware. Para uma máquina com n 
quadros de página, o hardware de LRU pode manter uma matriz de n x n bits, inicialmente 
todos iguais a zero. Quando o quadro de página k é referenciado, o hardware primeiramente 
configura todos os bits da linha k como 1 e, em seguida, configura todos os bits da coluna k 
como 0. Em qualquer instante, a linha cujo valor binário é o menor é a menos recentemente 
usada, a linha cujo valor é o próximo mais baixo é a página menos recentemente usada se- 
guinte e assim sucessivamente. O funcionamento desse algoritmo aparece na Figura 4-16 
para quatro quadros de página e referências de página na ordem 


0123210323 


Após a página 0 ser referenciada, temos a situação da Figura 4-16(a). Após a página 1 
ser referenciada, temos a situação da Figura 4-16(b) e assim por diante. 


Simulando o algoritmo LRU em software 


Embora, em princípio, os dois algoritmos LRU anteriores sejam realizáveis, poucas máquinas 
(se houver) têm esse hardware; portanto, eles têm pouca utilidade para o projetista de sistema 
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Figura 4-16 Algoritmo LRU usando uma matriz quando as páginas são referenciadas na 
ordem 0, 1,2,3,2,1,0,3,2,3. 


operacional que esteja fazendo um sistema para uma máquina que não tenha esse hardware. 
Em vez disso, é necessária uma solução que possa ser implementada em software. Uma pos- 
sível solução de software é o chamado algoritmo NFU (Not Frequently Used — não utilizada 
frequentemente). Ele exige um contador de software associado a cada página, inicialmente 
igual a zero. Em cada interrupção de relógio, o sistema operacional percorre todas as páginas 
na memória. Para cada página, o bit R, que é O ou 1, é adicionado no contador. Na verdade, 
os contadores são uma tentativa de monitorar a frequência com que cada página é referen- 
ciada. Quando ocorre uma falta de página, a página com o menor contador é escolhida para 
substituição. 

O principal problema do algoritmo NFU é que ele nunca se esquece de nada. Por exem- 
plo, em um compilador de múltiplas passagens, as páginas que foram muito utilizadas du- 
rante a passagem 1 ainda podem ter uma contagem alta nas últimas passagens. Na verdade, 
se acontecer de a passagem 1 ter o tempo de execução mais longo de todas as passagens, as 
páginas contendo o código das passagens subsegiientes podem ter sempre contagens menores 
do que as páginas da passagem 1. Assim, o sistema operacional removerá páginas úteis, em 
vez de páginas que não estão mais sendo usadas. 

Felizmente, uma pequena modificação no algoritmo NFU o torna capaz de simular mui- 
to bem o algoritmo LRU. A modificação tem duas partes. Primeiramente, cada contador é 
deslocado 1 bit para a direita, antes que o bit R seja adicionado. Segundo, o bit R é adicionado 
ao bit mais à esquerda, em vez do bit mais à direita. 

A Figura 4-17 ilustra o funcionamento do algoritmo modificado, conhecido como algo- 
ritmo do envelhecimento (aging). Suponha que, após o primeiro tique de relógio, o bit R das 
páginas de 0 a 5 tenham os valores 1,0, 1,0, 1 e 1 respectivamente (a página O é 1, a página 1 
é O, a página 2 é 1 etc.). Em outras palavras, entre o tique O e o tique 1, as páginas 0,2,4€e 5 
foram referenciadas, configurando seus bits R como 1, enquanto as outras permanecem como 
0. Após os seis contadores correspondentes terem sido deslocados e o bit R inserido à esquer- 
da, eles têm os valores mostrados na Figura 4-17(a). As quatro colunas restantes mostram os 
valores dos seis contadores após os próximos quatro tiques de relógio, respectivamente. 
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Bits R das Bits R das Bits R das Bits R das Bits R das 
páginas 0-5, tique | páginas 0-5, tique | páginas 0-5, tique | páginas 0-5, tique | páginas 0-5, tique 
de relógio O de relógio1 de relógio 2 i de relógio 3 de relógio 4 


‘ekolaj Haele aaoo [feo] 


Página 


0 10000000 11000000 01111000 


1 00000000 10000000 10110000 


2 10000000 01000000 10001000 


3 00000000 00000000 00100000 


4 10000000 11000000 01011000 


5 10000000 01000000 00101000 
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Figura 4-17 O algoritmo do envelhecimento simula o algoritmo LRU no software. São 
mostradas seis páginas para cinco tiques de relógio. Os cinco tiques de relógio são represen- 
tados por (a) a (e). 


Quando ocorre uma falta de página, a página cujo contador é o menor é removida. É 
claro que uma página que não foi referenciada por, digamos, quatro tiques de relógio, terá 
quatro zeros iniciais em seu contador e, assim, terá um valor menor do que um contador que 
não tenha sido referenciado por três tiques de relógio. 

Esse algoritmo difere do LRU sob dois aspectos. Considere as páginas 3 e 5 na Figura 
4-17(e). Nenhuma delas foi referenciada por dois tiques de relógio; ambas foram referen- 
ciadas no tique anterior a esses. De acordo com o algoritmo LRU, se uma página precisa ser 
substituída, devemos escolher uma dessas duas. O problema é que não sabemos qual dessas 
duas foi referenciada por último no intervalo entre o tique 1 e o tique 2. Registrando apenas 
um bit por intervalo de tempo, perdemos a capacidade de distinguir as referências que ocor- 
reram no início do intervalo do relógio daquelas que ocorreram depois. Tudo que podemos 
fazer é remover a página 3, pois a página 5 também foi referenciada dois tiques antes e a 
página 3, não. 

A segunda diferença entre os algoritmos LRU e do envelhecimento é que neste último 
os contadores têm um número finito de bits, 8 bits neste exemplo. Suponha que duas páginas 
tenham, cada uma, o valor de contador 0. Tudo que podemos fazer é escolher uma delas alea- 
toriamente. Na realidade, pode muito bem acontecer de uma das páginas ter sido referenciada 
pela última vez há 9 tiques atrás e a outra ter sido referenciada pela última vez há 1000 tiques 
atrás. Não temos meios de ver isso. Na prática, entretanto, 8 bits geralmente são suficientes, 
caso um tique de relógio tenha aproximadamente 20 ms. Se uma página não foi referenciada 
há 160 ms, provavelmente ela não é importante. 


QUESTÕES DE PROJETO PARA SISTEMAS DE PAGINAÇÃO 


Nas seções anteriores explicamos o funcionamento da paginação, fornecemos alguns dos 
algoritmos básicos de substituição de página e mostramos como modelá-los. Mas conhecer 
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apenas a mecânica não é suficiente. Para projetar um sistema, você precisa saber muito mais, 
para fazê-lo funcionar bem. É como a diferença entre saber como mover a torre, o cavalo e 
outras peças no xadrez e ser um bom enxadrista. Nas seções a seguir, veremos outros proble- 
mas que os projetistas de sistema operacional devem considerar para obter um bom desempe- 
nho de um sistema de paginação. 


O modelo do conjunto de trabalho 


Na forma mais pura da paginação, os processos são iniciados sem nenhuma de suas pági- 
nas na memória. Assim que a CPU tenta buscar a primeira instrução, ela obtém uma falta 
de página, fazendo o sistema operacional trazer a página que contém a primeira instrução. 
Normalmente, rapidamente ocorrem outras faltas de página devido aos acessos às variáveis 
globais e à pilha. Depois de algum tempo, o processo tem a maioria das páginas que precisa 
e estabiliza-se, executando com relativamente poucas faltas de página. Essa estratégia é cha- 
mada de paginação por demanda, pois as páginas são carregadas apenas sob demanda e não 
antecipadamente. 

É muito fácil escrever um programa de teste que leia sistematicamente todas as páginas 
de um espaço de endereçamento grande, provocando tantas faltas de página até um ponto em 
que não há memória suficiente para conter tudo. Felizmente, a maioria dos processos não 
funciona assim. Eles apresentam uma localidade de referência, significando que, durante 
qualquer fase da execução, o processo referencia apenas uma fração relativamente pequena 
de suas páginas. Cada passagem de um compilador de múltiplas passagens, por exemplo, 
referencia apenas uma fração das páginas e, mesmo assim, uma fração diferente. O conceito 
de localidade de referência é amplamente aplicável na ciência da computação; para ver uma 
história, consulte Denning (2005). 

O conjunto de páginas correntemente em uso por um processo é chamado de conjunto 
de trabalho, ou working set, no termo original (Denning, 1968a; Denning, 1980). Se o con- 
junto de trabalho inteiro estiver na memória, o processo será executado sem causar muitas 
faltas de página, até que se mova para outra fase da execução (por exemplo, a próxima passa- 
gem do compilador). Se a memória disponível for pequena demais para conter o conjunto de 
trabalho inteiro, o processo causará várias faltas de página e será executado lentamente, pois 
executar uma instrução demora alguns nanossegundos e ler uma página do disco normalmen- 
te leva 10 milissegundos. A uma taxa de uma ou duas instruções a cada 10 milissegundos, o 
processo demorará muito para terminar. Quando um programa gera muitas faltas de página 
para poucas instruções executadas, diz-se que ele está em ultrapaginação (thrashing) (Den- 
ning, 1968b). 

Em um sistema de multiprogramação, os processos são movidos para o disco frequen- 
temente (isto é, todas as suas páginas são removidas da memória) para permitir que outros 
processos tenham sua vez na CPU. Surge a questão do que fazer quando um processo é tra- 
zido de volta novamente. Tecnicamente, nada precisa ser feito. O processo apenas provocará 
várias faltas de página até que seu conjunto de trabalho tenha sido carregado. O problema é 
que ter 20, 100 ou mesmo 1000 faltas de página sempre que um processo é carregado é lento 
e também desperdiça um tempo considerável da CPU, pois o sistema operacional exige al- 
guns milissegundos do tempo da CPU para processar uma falta de página, sem mencionar a 
quantidade considerável de E/S de disco. 

Portanto, muitos sistemas de paginação tentam monitorar o conjunto de trabalho de cada 
processo e garantir que ele esteja na memória, antes de permitirem que o processo seja execu- 
tado. Essa estratégia é chamada de modelo do conjunto de trabalho (Denning, 1970). Ela foi 
projetada para reduzir substancialmente a taxa de falta de página. O carregamento das páginas 
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antes de permitir que os processos sejam executados também é chamado de pré-paginação. 
Note que o conjunto de trabalho muda com o passar do tempo. 

Sabe-se, há muito tempo, que a maioria dos programas não referencia seu espaço de 
endereçamento uniformemente. Em vez disso, as referências tendem a se concentrarem em 
um pequeno número de páginas. Uma referência de memória pode buscar uma instrução, 
buscar ou armazenar dados. Em qualquer instante de tempo, t, existe um conjunto composto 
por todas as páginas usadas pelas k referências de memória mais recentes. Esse conjunto, w(k, 
t), é o conjunto de trabalho. Um valor maior de k significa considerar mais o histórico passado 
de acesso a páginas. O número de páginas que compõem o conjunto de trabalho não pode 
diminuir à medida que k se torna maior. Portanto, w(k, t) é uma função monotônica não-de- 
crescente de k. O limite de w(k, t), à medida que k se torna maior, é finito, pois um programa 
não pode referenciar mais páginas do que seu espaço de endereçamento contém, e poucos 
programas usarão todas as páginas. A Figura 4-18 mostra o tamanho do conjunto de trabalho 
como uma função de k. 


w(k,t) 


k 


Figura 4-18 O conjunto de trabalho é o conjunto das páginas usadas pelas k referências de 
memória mais recentes. A função w(k, t) é o tamanho do conjunto de trabalho no tempo t. 


O fato de que a maioria dos programas acessa aleatoriamente um pequeno número de 
páginas, mas que esse conjunto muda lentamente no tempo, explica a rápida subida inicial da 
curva e depois um crescimento lento à medida que k aumenta. Por exemplo, um programa que 
esteja executando um laço que ocupa duas páginas e que acessa dados localizados em quatro 
páginas, pode referenciar todas as seis páginas a cada 1000 instruções, mas a referência mais 
recente para alguma outra página pode ter sido a um milhão de instruções atrás, durante a fase 
de inicialização. Devido a esse comportamento assintótico, o conteúdo do conjunto de traba- 
lho não é sensível ao valor de k escolhido. Mais exatamente, em outras palavras, existe uma 
ampla gama de valores k para os quais o conjunto de trabalho não muda. Como o conjunto de 
trabalho varia lentamente com o tempo, é possível ter um palpite razoável sobre quais páginas 
serão necessárias quando o programa for reiniciado, com base em seu conjunto de trabalho 
no momento em que foi interrompido pela última vez. A pré-paginação consiste em carregar 
essas páginas antes que o processo tenha permissão para ser executado novamente. 

Para implementar o modelo do conjunto de trabalho, é necessário que o sistema ope- 
racional monitore quais páginas estão no conjunto de trabalho. Uma maneira de monitorar 
essa informação é usar o algoritmo do envelhecimento discutido anteriormente. Qualquer 
página contendo um bit 1 entre os n bits de ordem superior do contador é considerada mem- 
bro do conjunto de trabalho. Se uma página não for referenciada em n tiques consecutivos 
de relógios, ela é retirada do conjunto de trabalho. O parâmetro n precisa ser determinado 
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experimentalmente para cada sistema, mas o desempenho do sistema normalmente não é 
particularmente sensível ao valor exato. 

As informações sobre o conjunto de trabalho podem ser usadas para melhorar o desem- 
penho do algoritmo do relógio. Normalmente, quando o ponteiro aponta para uma página 
cujo bit R é 0, a página é retirada da memória. O aprimoramento é verificar se essa página faz 
parte do conjunto de trabalho do processo corrente. Se fizer, a página é poupada. Esse algorit- 
mo é chamado de wsclock, de working set para o algoritmo do relógio (clock). 


Políticas de alocação local versus global 


Nas seções anteriores, discutimos vários algoritmos para escolher uma página para substituir 
quando ocorre uma falta. Um problema importante associado a essa escolha (que, até agora, 
varremos cuidadosamente para baixo do tapete) é como a memória deve ser alocada entre os 
processos concorrentes. 

Dê uma olhada na Figura 4-19(a). Nessa figura, três processos, A, B e C, compõem o 
conjunto de processos em execução. Suponha que A gere uma falta de página. O algoritmo 
de substituição de página deve tentar encontrar a página utilizada menos recentemente con- 
siderando apenas as seis páginas correntemente alocadas para A ou deve considerar todas as 
páginas que estão na memória? Se ele examinar apenas as páginas de 4, a página com o valor 
de idade mais baixo será A5; então, teremos a situação da Figura 4-19(b). 

Por outro lado, se a página com o valor de idade mais baixo for removida sem conside- 
rar a quem pertence essa página, a página B3 será escolhida e teremos a situação da Figura 
4-19(c). O algoritmo da Figura 4-19(b) é chamado de algoritmo de substituição de página 
local, enquanto o da Figura 4-19(c) é chamado de algoritmo global. Os algoritmos locais 
correspondem efetivamente a alocar uma fração fixa da memória para cada processo. Os 
algoritmos globais alocam quadros de página dinamicamente entre os processos executáveis. 
Assim, o número de quadros de página atribuídos a cada processo varia com o tempo. 

Em geral, os algoritmos globais funcionam melhor, especialmente quando o tamanho 
do conjunto de trabalho pode variar durante o tempo de vida de um processo. Se for usado um 
algoritmo local e o conjunto de trabalho crescer, isso resultará em ultrapaginação, mesmo que 
existam muitos quadros de página livres. Se o conjunto de trabalho diminuir, os algoritmos 


N 


(b) 


Figura 4-19 Substituição de página local versus global. (a) Configuração original. (b) Subs- 
tituição de página local. (c) Substituição de página global. 
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locais desperdiçarão memória. Se for usado um algoritmo global, o sistema deverá decidir 
continuamente quantos quadros de página devem ser atribuídos para cada processo. Uma 
maneira de fazer isso é monitorar o tamanho do conjunto de trabalho, conforme indicado 
pelos bits de envelhecimento, mas essa estratégia não evita necessariamente a ultrapaginação. 
O conjunto de trabalho pode mudar de tamanho em questão de microssegundos, enquanto os 
bits de envelhecimento são uma medida grosseira, abrangendo vários tiques de relógio. 

Outra estratégia é ter um algoritmo para alocar quadros de página para os processos. 
Uma maneira de fazer isso é determinar periodicamente o número de processos em execução e 
alocar a cada processo uma parte igual. Assim, com 12.416 quadros de página disponíveis (isto 
é, não pertencentes ao sistema operacional) e 10 processos, cada processo recebe 1241 qua- 
dros. Os 6 restantes ficam em um pool para serem usados quando ocorrerem faltas de página. 

Embora esse método pareça justo, faz pouco sentido dar partes iguais da memória para 
um processo de 10 KB e para um processo de 300 KB. Em vez disso, as páginas podem ser 
alocadas na proporção do tamanho total de cada processo, com um processo de 300 KB 
recebendo 30 vezes mais do que a parte destinada a um processo de 10 KB. Provavelmente 
é sensato dar a cada processo algum número mínimo, para que ele possa ser executado sem 
provocar muitas faltas de página independentemente de ser grande ou pequeno. Em algumas 
máquinas, por exemplo, uma única instrução de dois operandos talvez precise, no pior caso, 
de até seis páginas, pois a instrução em si, o operando de origem e o operando de destino 
podem ultrapassar os limites de uma página. Com uma alocação de apenas cinco páginas, os 
programas contendo tais instruções não podem ser executados. 

Se for usado um algoritmo global, pode-se iniciar cada processo com um número de 
páginas proporcional ao tamanho do processo, mas a alocação precisa ser atualizada dinami- 
camente, à medida que os processos são executados. Uma maneira de gerenciar a alocação é 
usar o algoritmo de fregiiência de faltas de páginas — FFP (Page Fault Frequency — PFF). 
Ele diz quando aumentar ou diminuir a alocação de página de um processo, mas não diz nada 
sobre qual página substituir no caso de uma falta de página. Ele apenas controla o tamanho 
do conjunto alocado. 

Para muitos algoritmos de substituição de página, incluindo o LRU, sabe-se que a taxa 
de faltas diminui à medida que mais páginas são atribuídas, conforme discutimos anterior- 
mente. Essa é a suposição que há por trás do algoritmo FFP. Essa propriedade está ilustrada 
na Figura 4-20. 


Faltas de página/s 


Número de quadros de página atribuídos 


Figura 4-20 Taxa de faltas de página como uma função do número de quadros de página 
atribuídos. 


Medir a taxa de faltas de página é simples: basta contar a quantidade de vezes que elas 
ocorrem por segundo, possivelmente tirando também a média dos segundos passados. Uma 
maneira fácil de fazer isso é somar o valor do segundo presente à média corrente e dividir por 
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dois. A linha tracejada A corresponde a uma taxa de faltas de página inaceitavelmente alta, 
de modo que o processo falho recebe mais quadros de página para reduzir a taxa de faltas. A 
linha tracejada B corresponde a uma taxa de faltas de página tão baixa que se pode concluir 
que o processo tem memória demais. Nesse caso, quadros de página podem ser retirados dele. 
Assim, o algoritmo FFP tenta manter a taxa de paginação de cada processo dentro de limites 
aceitáveis. 

Se o algoritmo descobre que existem tantos processos na memória que não é possível 
manter todos eles abaixo de 4, então algum processo é removido da memória e seus quadros 
de página são divididos entre os processos restantes ou colocados em um pool de quadros 
de páginas disponíveis que podem ser usados nas faltas de página subsequentes. A decisão 
de remover um processo da memória é uma forma de controlar a carga do sistema (load 
control). Ela mostra que, mesmo com paginação, o swapping ainda é necessário, somente 
que agora ele é usado para reduzir a demanda de memória em potencial, em vez de recuperar 
blocos para uso imediato. A colocação de processos no disco para aliviar a carga na memória 
recorda o escalonamento em dois níveis, no qual alguns processos são postos no disco (es- 
calonador de médio prazo) e um escalonador de curto prazo é utilizado selecionar qual dos 
processos restantes (em memória) utilizará o processador. Claramente, as duas idéias podem 
ser combinadas, com apenas processos suficientes colocados no disco para tornar a taxa de 
faltas de página aceitável. 


Tamanho de página 


O tamanho da página é fregiientemente um parâmetro que pode ser escolhido pelo sistema 
operacional. Mesmo que o hardware tenha sido projetado para páginas de 512 bytes, por 
exemplo, o sistema operacional pode considerar facilmente as páginas 0 e 1, 2 e 3, 4 e 5 etc., 
como páginas de 1 KB, alocando sempre dois quadros de página de 512 bytes consecutivos 
para cada uma delas. 

Determinar o melhor tamanho de página exige contrabalançar vários fatores conflitan- 
tes. Como resultado, não há uma situação ótima geral. Para começar, existem dois fatores 
a favor de um tamanho de página pequeno. Um segmento de texto, de dados ou de pilha 
escolhido aleatoriamente não preencherá um número de páginas integral. Em média, metade 
da última página ficará vazia. O espaço extra nessa página é desperdiçado. Esse desperdício 
é chamado de fragmentação interna. Com n segmentos na memória e com um tamanho de 
página de p bytes, np/2 bytes serão desperdiçados na fragmentação interna. Esse é um fator a 
favor de um tamanho de página pequeno. 

Outro argumento a favor de um tamanho de página pequeno se torna evidente se pen- 
sarmos em um programa consistindo em oito fases seqüenciais de 4 KB cada uma. Com um 
tamanho de página de 32 KB, deve-se alocar 32 KB para o programa o tempo todo. Com um 
tamanho de página de 16 KB, são necessários apenas 16 KB. Com um tamanho de página de 
4 KB ou menos, são necessários apenas 4 KB em dado instante. Em geral, um tamanho de 
página grande fará com que mais porções não utilizadas de um programa estejam carregadas 
em memória do que com um tamanho de página pequeno. 

Por outro lado, páginas pequenas significam que os programas precisarão de muitas 
páginas e, daí, uma tabela de páginas grande. Um programa de 32 KB precisa somente de 
quatro páginas de 8 KB, mas 64 páginas de 512 bytes. As transferências para o disco (e dele 
para a memória) geralmente são feitas uma página por vez, sendo a maior parte do tempo 
gasta no tempo de busca (seek) e atraso rotacional (rotational delay), de modo que transferir 
uma página pequena demora quase o mesmo tempo que transferir uma página grande. Pode- 
ria demorar 10 ms para carregar cada uma das 64 páginas de 512 bytes, mas apenas 10,1 ms 
para carregar cada página de 8 KB. 
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Em algumas máquinas, a tabela de páginas precisa ser carregada em registradores de 
hardware sempre que a CPU troca de um processo para outro. Nessas máquinas, ter um tama- 
nho de página pequeno significa que o tempo exigido para carregar os registradores de página 
fica maior à medida que o tamanho da página fica menor. Além disso, o espaço ocupado pela 
tabela de páginas aumenta à medida que o tamanho da página diminui. 

Este último ponto pode ser analisado matematicamente. Suponha que o tamanho médio 
dos processos seja de s bytes e que o tamanho de página seja de p bytes. Além disso, suponha 
que cada entrada de página exija e bytes. Então, o número aproximado de páginas necessá- 
rias por processo é de s/p, ocupando se/p bytes de espaço na tabela de páginas. A memória 
desperdiçada na última página do processo, devido à fragmentação interna, é de p/2. Assim, 
a sobrecarga total devida à tabela de páginas e à perda pela fragmentação interna é dada pela 
soma desses dois termos: 


sobrecarga = se/p + p/2 


O primeiro termo (tamanho da tabela de páginas) é grande quando o tamanho da página 
é pequeno. O segundo termo (fragmentação interna) é grande quando o tamanho da página é 
grande. O valor ótimo deve estar em algum lugar entre os dois. Tomando a primeira derivada 
com relação à p e igualando-a a zero, obtemos a equação 


-se/p +1/2=0 


A partir dessa equação, podemos derivar uma fórmula para fornecer o tamanho de pá- 
gina ótimo (considerando apenas a memória desperdiçada na fragmentação e no tamanho da 
tabela de páginas). O resultado é: 


p=2se 


Para s = IMB e e = 8 bytes por entrada da tabela de páginas, o tamanho de página ótimo 
será de 4 KB. Os computadores disponíveis comercialmente têm usado tamanhos de página 
que variam de 512 bytes a 1 MB. Um valor típico costumava ser 1 KB, mas hoje em dia, 4 KB 
ou 8 KB são mais comuns. À medida que as memórias ficam maiores, o tamanho de página 
tende a ficar maior também (mas não linearmente). Quadruplicar o tamanho da memória 
RAM raramente duplica o tamanho da página. 


Interface de memória virtual 


Até agora, nossa discussão inteira pressupôs que a memória virtual é transparente para pro- 
cessos e programadores. Isto é, tudo que eles vêem é um grande espaço de endereçamento 
virtual em um computador com uma memória física pequena (menor). No caso de muitos 
sistemas, isso é verdade, mas em alguns sistemas avançados os programadores têm algum 
controle sobre o mapa de memória e podem usá-lo de maneiras não tradicionais para melho- 
rar o comportamento do programa. Nesta seção, veremos brevemente algumas delas. 

Uma razão para dar aos programadores o controle sobre seus mapas de memória é 
permitir que dois ou mais processos compartilhem a mesma memória. Se os programadores 
puderem dar nomes às regiões de suas memórias, será possível um processo fornecer a outro 
o nome de uma região de memória para que esse processo também possa fazer o mapeamento 
nela. Com dois (ou mais) processos compartilhando as mesmas páginas, torna-se possível um 
alto compartilhamento de largura de banda: um processo escreve na memória compartilhada 
e o outro lê. 


CAPÍTULO 4 e (GERENCIAMENTO DE MEMÓRIA 383 


4.6 


O compartilhamento de páginas também pode ser usado para implementar um sistema 
de passagem de mensagens de alto desempenho. Normalmente, quando as mensagens são 
passadas, os dados são copiados de um espaço de endereçamento para outro a um custo 
considerável. Se os processos puderem controlar seus mapas de página, uma mensagem po- 
derá ser passada, com o processo remetente desfazendo o mapeamento da(s) página(s) que 
contém(êm) a mensagem e o processo receptor mapeando-a(s) novamente. Aqui, apenas os 
nomes de página precisam ser copiados, em vez de todos os dados. 

Uma outra técnica avançada de gerenciamento de memória é a memória comparti- 
lhada distribuída (Feeley et al., 1995; Li e Hudak, 1989; e Zekauskas et al., 1994). A idéia 
aqui é permitir que vários processos em uma rede compartilhem um conjunto de páginas, 
possivelmente (mas não necessariamente) como um único espaço de endereçamento linear 
compartilhado. Quando um processo referencia uma página que não está correntemente ma- 
peada, obtém uma falta de página. Então, a rotina de tratamento de falta de página, que pode 
estar em espaço de núcleo ou em espaço de usuário, localiza a máquina que contém a página 
e envia para ela uma mensagem pedindo para que desfaça o mapeamento da página e a envie 
pela rede. Quando a página chega, é mapeada e a instrução que provocou a falta de página é 
reiniciada. 


SEGMENTAÇÃO 


A memória virtual discutida até aqui é unidimensional, pois os endereços virtuais vão de O até 
algum endereço máximo, um endereço após o outro. Para muitos problemas, ter dois ou mais 
espaços de endereçamento virtuais separados pode ser muito melhor do que ter apenas um. 
Por exemplo, um compilador tem muitas tabelas que são construídas à medida que a compi- 
lação prossegue, possivelmente incluindo: 


1. O salvamento do texto do código-fonte para a listagem impressa (em sistemas de 
lote). 
A tabela de símbolos, contendo os nomes e atributos das variáveis. 


A tabela contendo todas as constantes inteiras e em ponto flutuante usadas. 


E ad o 


A árvore de análise, contendo a análise sintática do programa. 


5. A pilha usada para chamadas de função dentro do compilador. 


Cada uma das quatro primeiras tabelas cresce continuamente, à medida que a compila- 
ção prossegue. A última aumenta e diminui de maneiras imprevisíveis durante a compilação. 
Em uma memória unidimensional, para essas cinco tabelas, teriam de ser alocados trechos 
adjacentes do espaço de endereçamento virtual, como se vê na Figura 4-21. 

Considere o que acontecerá se um programa tiver um número excepcionalmente grande 
de variáveis, mas uma quantidade normal do restante. O trecho do espaço de endereçamento 
alocado para a tabela de símbolos poderá ser totalmente preenchido, mas ainda poderá haver 
muito espaço disponível nas outras tabelas. Naturalmente, o compilador poderia simplesmen- 
te emitir uma mensagem dizendo que a compilação não pode continuar devido à existência de 
variáveis demais, mas fazer isso não parece muito justo, quando resta espaço sem utilização 
nas outras tabelas. 

Outra possibilidade é brincar de Robin Hood, roubando espaço das tabelas com excesso 
de espaço e dando-o para as tabelas com pouco espaço. Essa troca pode ser feita, mas é aná- 
logo a gerenciar os próprios overlays — na melhor das hipóteses, um incômodo, e, na pior, um 
trabalho enorme e sem recompensa. 
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Espaço de endereçamento virtual 


Pilha de cnamadas 
Espaço de } Livre 
endereçamento 
alocado para a 
árvore de análise 
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Árvore de análise 
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A tabela de símbolos 
Tabela de símbolos colidiu com a tabela 
do texto do código-fonte 


Figura 4-21 Em um espaço de endereçamento unidimensional com tabelas que crescem, 
uma tabela pode colidir com outra. 


O que é realmente necessário é uma maneira de fazer com que o programador não tenha 
que gerenciar o aumento e a redução das tabelas, da mesma maneira que a memória virtual 
elimina a preocupação de organizar o programa em overlays. 

Uma solução simples e extremamente geral é fornecer à máquina vários espaços de 
endereçamento completamente independentes, chamados de segmentos. Cada segmento con- 
siste em uma sequência linear de endereços, de O até algum máximo. O comprimento de cada 
segmento pode ser qualquer um, de O até o máximo permitido. Diferentes segmentos podem 
ter (e normalmente têm) comprimentos diferentes. Além disso, o comprimento dos segmen- 
tos pode mudar durante a execução. O comprimento de um segmento de pilha pode aumentar 
quando algo for colocado na pilha e diminuir quando algo for retirado dela. 

Como cada segmento constitui um espaço de endereçamento separado, diferentes seg- 
mentos podem aumentar ou diminuir independentemente, sem afetar uns aos outros. Se uma 
pilha em determinado segmento precisa de mais espaço de endereçamento para crescer, ela 
pode tê-lo, pois não há mais nada em seu espaço de endereçamento para colidir. É claro que 
um segmento pode ser preenchido, mas os segmentos normalmente são muito grandes, de 
modo que essa ocorrência é rara. Para especificar um endereço nessa memória segmentada, 
ou bidimensional, o programa precisa fornecer um endereço de duas partes, um número de 
segmento e um endereço dentro do segmento. A Figura 4-22 ilustra uma memória segmen- 
tada sendo usada para as tabelas de compilador discutidas anteriormente. Cinco segmentos 
independentes são mostrados aqui. 

Salientamos que, em sua forma mais pura, um segmento é uma entidade lógica, da qual 
o programador está ciente e a usa como tal. Um segmento pode conter uma ou mais funções, 
um array, uma pilha ou um conjunto de variáveis escalares, mas normalmente ele não contém 
uma mistura de tipos diferentes. 

Uma memória segmentada tem outras vantagens, além de simplificar a manipulação de 
estruturas de dados que crescem ou diminuem. Se cada função ocupa um segmento separado, 
com o endereço 0 como seu endereço inicial, a ligação de funções compiladas separadamente 
é bastante simplificada. Depois que todas as funções que constituem um programa tiverem 
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Figura 4-22 Uma memória segmentada permite que cada tabela aumente ou diminua inde- 
pendentemente das outras tabelas. 


sido compiladas e ligadas, uma chamada para a função no segmento n usará o endereço de 
duas partes (n, 0) para endereçar a palavra O (o ponto de entrada). 

Se a função no segmento n for subsequentemente modificada e recompilada, nenhuma 
outra função precisará ser alterada (pois nenhum endereço inicial foi modificado), mesmo que 
a nova versão seja maior do que a antiga. Com uma memória unidimensional, as funções são 
concisamente empacotadas uma ao lado da outra, sem nenhum espaço de endereçamento entre 
elas. Conseqiientemente, alterar o tamanho de uma função pode afetar o endereço inicial de ou- 
tras funções não relacionadas. Isso, por sua vez, exige modificar todas as funções que chamam 
qualquer uma das funções deslocadas por essa alteração para incorporar seus novos endereços 
iniciais. Se um programa contém centenas de funções, esse processo pode ser dispendioso. 

A segmentação também facilita o compartilhamento de funções ou dados entre vários 
processos. Um exemplo comum é o de biblioteca compartilhada. As estações de trabalho mo- 
dernas que executam avançados sistemas de janelas, frequentemente têm bibliotecas gráficas 
extremamente grandes compiladas em praticamente todo programa. Em um sistema segmenta- 
do, a biblioteca gráfica pode ser colocada em um segmento e compartilhada por vários proces- 
sos, eliminando a necessidade de tê-la no espaço de endereçamento de cada processo. Embora 
também seja possível ter bibliotecas compartilhadas nos sistemas de paginação puros, isso é 
muito mais complicado. Na verdade, esses sistemas fazem isso simulando a segmentação. 

Como cada segmento forma uma entidade lógica da qual o programador está ciente, 
como uma função, um array ou uma pilha, diferentes segmentos podem ter diferentes tipos 
de proteção. Um segmento de função pode ser especificado como apenas de execução, proi- 
bindo tentativas de leitura ou de armazenamento de dados nele. Um array em ponto flutuante 
pode ser especificado como de leitura/escrita, mas não execução, e as tentativas de “executá- 
lo” serão detectadas. Tal proteção é útil na identificação de erros de programação. 

Você deve tentar entender por que a proteção faz sentido em uma memória segmentada, 
mas não em uma memória paginada unidimensional. Em uma memória segmentada, o usuá- 
rio está ciente do que há em cada segmento. Normalmente, um segmento não conteria uma 
função e uma pilha, por exemplo, mas uma ou a outra. Como cada segmento contém apenas 
um tipo de objeto, o segmento pode ter a proteção apropriada para esse tipo em particular. A 
paginação e a segmentação são comparadas na Figura 4-23. 
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Consideração Paginação Segmentação 
O programador precisa estar ciente de Não Sim 
que essa técnica está sendo utilizada? 
Quantos espaços de endereços lineares 1 Muitos 
existem? 
O espaço de endereçamento total pode Sim Sim 
ultrapassar o tamanho da memória 
física? 
As funções e os dados podem Não Sim 
ser distinguidos e protegidos 
separadamente? 


As tabelas cujo tamanho varia podem Não Sim 
ser acomodadas facilmente? 


O compartilhamento de funções entre os | Não Sim 
usuários é facilitado? 


Por que essa técnica foi inventada? Para se obter Para permitir que 
um espaço de programas e dados sejam 
endereçamento linear | divididos em espaços de 
sem ter de comprar endereçamento logicamente 
mais memória física independentes e para ajudar 
no compartilhamento e na 
proteção 


Figura 4-23 Comparação entre paginação e segmentação. 


De certo modo, o conteúdo de uma página é acidental. O programador ignora até mes- 
mo o fato de que a paginação está ocorrendo. Embora fosse possível colocar alguns bits em 
cada entrada da tabela de páginas para especificar o acesso permitido, o programador para 
utilizar esse recurso teria de monitorar onde estariam todos os limites de página em seu espa- 
ço de endereçamento. Entretanto, a paginação foi inventada para eliminar precisamente esse 
tipo de gerenciamento mais complexo. Como o usuário de uma memória segmentada tem a 
ilusão de que todos os segmentos estão o tempo todo na memória principal — isto é, ele pode 
endereçá-los como se estivessem lá —, ele pode proteger cada segmento separadamente, sem 
precisar se preocupar com a administração de overlays. 


Implementação da segmentação pura 


A implementação da segmentação difere da paginação de uma maneira fundamental: as 
páginas têm tamanho fixo e os segmentos, não. A Figura 4-24(a) mostra um exemplo de me- 
mória física contendo inicialmente cinco segmentos. Agora, considere o que acontece se o 
segmento 1 é eliminado e o segmento 7, que é menor, for colocado em seu lugar. Chegamos 
à configuração de memória da Figura 4-24(b). Entre o segmento 7 e o segmento 2 existe uma 
área não utilizada — isto é, uma lacuna. Então, o segmento 4 é substituído pelo segmento 5, 
como na Figura 4-24(c), e o segmento 3 é substituído pelo segmento 6, como na Figura 4- 
24(d). Depois que o sistema tiver executado por algum tempo, a memória será dividida em 
várias porções, algumas contendo segmentos e outras contendo lacunas. Esse fenômeno, 
chamado de checkboarding (formação de um tabuleiro de xadrez) ou fragmentação exter- 
na, desperdiça memória nas lacunas. Isso pode ser tratado com compactação, como se vê na 
Figura 4-24(e). 
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Figura 4-24 (a)-(d) Desenvolvimento da fragmentação externa. (e) Eliminação da fragmen- 
tação externa pela compactação. 
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Segmentação com paginação: o Pentium Intel 


O Pentium suporta até 16K segmentos, cada um com até > bytes de espaço de endereça- 
mento virtual. O Pentium pode ser configurado (pelo sistema operacional) para usar apenas 
segmentação, apenas paginação ou ambos. A maioria dos sistemas operacionais, incluindo 
o Windows XP e todos os tipos de UNIX, usa o modelo de paginação puro, no qual cada 
processo tem um único segmento de a bytes. Como o Pentium é capaz de fornecer aos pro- 
cessos um espaço de endereçamento muito maior, e apenas um sistema operacional (0S/2) 
usava todo esse poder de endereçamento, descreveremos o funcionamento da memória virtual 
do Pentium em toda sua generalidade. 

O centro da memória virtual do Pentium consiste em duas tabelas, a LDT (Local Des- 
criptor Table — tabela de descritores local) e a GDT (Global Descriptor Table — tabela de 
descritores global). Cada programa tem sua própria LDT, mas há apenas uma GDT, compar- 
tilhada por todos os programas no computador. A LDT descreve os segmentos locais de cada 
programa, incluindo seu código, dados, pilha etc., enquanto a GDT descreve os segmentos de 
sistema, incluindo o sistema operacional em si. 

Para acessar um segmento, um programa primeiro carrega um seletor para esse segmen- 
to em um dos seis registradores de segmento do processador. Durante a execução, o registra- 
dor CS armazena o seletor do segmento de código e o registrador DS armazena o seletor do 
segmento de dados. Os outros registradores de segmento são menos importantes. Cada seletor 
é um número de 16 bits, como se vê na Figura 4-25. 

Um dos bits do seletor informa se o segmento é local ou global (isto é, se ele está na 
LDT ou na GDT). Outros 13 bits especificam o número de entrada da LDT ou da GDT, por- 


Bits 


0 =GDT/1 =LDT Nível de privilégio (0-3) 


Figura 4-25 Um seletor do Pentium. 
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tanto, cada uma das tabelas está restrita a conter 8K descritores de segmento. Os outros 2 bits 
estão relacionados com a proteção e serão descritos posteriormente. O descritor O é proibido. 
Ele pode ser carregado com segurança em um registrador de segmento para indicar que o 
registrador de segmento não está disponível correntemente. Se for usado, ele causará uma 
interrupção de software (trap). 

No momento em que um seletor é carregado em um registrador de segmento, o descritor 
correspondente é buscado da LDT ou da GDT e armazenado em registradores internos para 
que possa ser acessado rapidamente. Um descritor consiste em 8 bytes, incluindo o endereço 
de base, o tamanho e outras informações do segmento, como se vê na Figura 4-26. 


0: O segmento está ausente da memória 
1: O segmento está presente na memória 
Nível de privilégio (0-3) 

O: Sistema 

1: Aplicativo 


0: Segmento de 16 bits 
1: Segmento de 32 bits 


O: Limite está em bytes 


1: Limite está em páginas 
Tipo e proteção do segmento 
7 


Base 24-31 G ø rA DPL|S| Tipo Base 16-23 
PD) 16-19 


Base 0-15 Limite 0-15 


= Endereço 
relativo 


= 32 Bits 


Figura 4-26 O descritor de segmento de código do Pentium. Os segmentos de dados dife- 
rem ligeiramente. 


O formato do seletor foi inteligentemente escolhido para facilitar a localização do des- 
critor. Primeiro, a LDT ou a GDT é selecionada, com base no terceiro bit menos significativo 
do seletor. Então, o seletor é copiado em um registrador de rascunho interno e os 3 bits de 
ordem inferior são configurados como 0. Finalmente, o endereço da tabela LDT ou da tabela 
GDT é somado a ele, para fornecer um ponteiro direto para o descritor. Por exemplo, o seletor 
72 se refere à entrada 9 na GDT, que está localizado no endereço GDT + 72. 

Vamos seguir as etapas pelas quais um par (seletor, deslocamento) é convertido em um 
endereço físico. Logo que o microprograma de controle do processador sabe qual registrador 
de segmento está sendo usado, ele pode localizar o descritor completo correspondente a esse 
seletor em seus registradores internos. Se o segmento não existe (seletor 0) ou não está cor- 
rentemente em memória, ocorre uma interrupção (trap). 

Na segiiência, ele verifica se o deslocamento está além do fim do segmento, no caso em 
que também ocorre uma interrupção. Logicamente, deve haver simplesmente um campo de 
32 bits no descritor fornecendo o tamanho do segmento, mas existem apenas 20 bits disponí- 
veis; dessa forma, é usado um esquema diferente. Se o campo bit G (Granularidade) for 0, o 
campo limite será o tamanho exato do segmento, até 1 MB. Se ele for 1, o campo limite forne- 
cerá o tamanho do segmento em páginas, em vez de bytes. O tamanho de página do Pentium 
é fixado em 4 KB; portanto, 20 bits são suficientes para segmentos de até cia bytes. 

Supondo que o segmento esteja na memória e o deslocamento esteja no intervalo corre- 
to, o Pentium adicionará ao deslocamento o campo base de 32 bits no descritor, para formar 
o que é chamado de endereço linear, como se vê na Figura 4-27. O campo base é dividido 
em três partes e distribuído por todo o descritor para manter a compatibilidade com o 286, no 
qual o campo base tem apenas 24 bits. Na verdade, o campo base permite que cada segmento 
comece em um lugar arbitrário dentro de um espaço de endereçamento linear de 32 bits. 
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Descritor 
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Limite 


Outros campos 


Endereço linear de 32 bits 


Figura 4-27 Conversão de um par (seletor, deslocamento) em um endereço linear. 


Se a paginação estiver desativada (por um bit em um registrador de controle global), o 
endereço linear será interpretado como o endereço físico e enviado para a memória para lei- 
tura ou escrita. Assim, com a paginação desativada, temos um esquema de segmentação puro, 
com o endereço de base de cada segmento dado em seu descritor. Casualmente, os segmentos 
podem se sobrepor, provavelmente porque daria muito trabalho e demoraria muito tempo 
para verificar se todos estariam disjuntos. 

Por outro lado, se a paginação estiver ativada, o endereço linear será interpretado como 
um endereço virtual e mapeado no endereço físico usando tabelas de página, de maneira 
muito parecida com nossos exemplos anteriores. A única complicação real é que, com um 
endereço virtual de 32 bits e uma página de 4 KB, um segmento poderia conter 1 milhão de 
páginas; portanto, é usado um mapeamento em dois níveis para reduzir o tamanho da tabela 
de páginas para segmentos menores. 

Cada programa em execução tem um diretório de páginas composto por 1024 entradas 
de 32 bits. Ele está localizado em um endereço apontado por um registrador global. Cada 
entrada nesse diretório aponta para uma tabela de páginas que também contém 1024 entradas 
de 32 bits. As entradas da tabela de páginas apontam para quadros de página. O esquema 
aparece na Figura 4-28. 

Na Figura 4-28(a), vemos um endereço linear dividido em três campos, dir, página e 
deslocamento. O campo dir é usado como índice no diretório de páginas para localizar um 
ponteiro para a tabela de páginas correta. Em seguida, o campo página é usado como índice 
na tabela de páginas para localizar o endereço físico do quadro de página. Finalmente, deslo- 
camento é somado ao endereço do quadro de página para obter o endereço físico do byte ou 
da palavra necessária. 

As entradas da tabela de páginas têm 32 bits cada uma, 20 dos quais contêm um número 
de quadro de página. Os bits restantes são para controle (referência e sujo), configurados pelo 
hardware para proveito do sistema operacional, para proteção e para outros fins. 

Cada tabela de páginas tem entradas para 1024 quadros de página de 4 KB; portanto, 
uma única tabela de páginas manipula 4 megabytes de memória. Um segmento menor do 
que 4 MB terá um diretório de páginas com uma única entrada, um ponteiro para sua única 
tabela de páginas. Desse modo, a sobrecarga dos segmentos pequenos é de somente duas 
páginas, em vez dos milhões de páginas que seriam necessárias em uma tabela de páginas 
de um nível apenas. 

Para evitar referências repetidas à memória, o Pentium tem um TLB pequeno que faz 
o mapeamento direto das combinações dir-página mais recentemente usadas no endereço 
físico do quadro de página. Somente quando a combinação corrente não está presente no TLB 
é que o mecanismo da Figura 4-28 é realmente executado e o TLB atualizado. Desde que as 
faltas na TLB sejam raras, o desempenho será bom. 
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Endereço linear 


Bits 10 10 12 
(a) 
Diretório de páginas Tabela de páginas Quadro de página 
Palavra 
selecionada 
1024 
entradas! 
Dir 


A entrada de A entrada da 
diretório aponta para tabela de páginas 
a tabela de páginas aponta para a palavra 


(b) 


Figura 4-28 Mapeamento de um endereço linear em um endereço físico. 


Pensando um pouco, percebemos que, quando é usada paginação, não há motivo para 
que o campo base no descritor seja diferente de zero. Tudo que esse campo faz é causar um 
pequeno deslocamento para usar uma entrada no meio do diretório de páginas, em vez do 
início. O motivo real para incluir o campo base é permitir a segmentação pura (não paginada) 
e para manter a compatibilidade com o 286, que sempre tem a paginação desativada (isto é, o 
286 tem apenas segmentação pura, mas não tem paginação). 

Também vale notar que, se algum aplicativo não precisar de segmentação, mas estiver 
satisfeito com um único espaço de endereçamento paginado de 32 bits, esse modelo será 
possível. Todos os registradores de segmento podem ser configurados com o mesmo seletor, 
cujo descritor tem base = 0 e limite configurado com o máximo. Então, o deslocamento da 
instrução será o endereço linear, com apenas um espaço de endereçamento usado — com efei- 
to, uma paginação normal. Na verdade, todos os sistemas operacionais atuais para o Pentium 
funcionam assim. O OS/2 era o único que usava o poder total da arquitetura MMU da Intel. 

Considerando tudo, devemos parabenlizar os projetistas do Pentium. Dados os objeti- 
vos conflitantes da implementação da paginação pura, da segmentação pura e dos segmentos 
paginados e, ao mesmo tempo, ser compatível com o 286, e fazer tudo isso eficientemente, o 
projeto resultante é surpreendentemente simples e limpo. 

Embora tenhamos abordado a arquitetura completa da memória virtual do Pentium, 
mesmo que resumidamente, vale dizer algumas palavras sobre proteção, pois esse assunto 
está intimamente relacionado com a memória virtual. O Pentium suporta quatro níveis de 
proteção, sendo o nível O o mais privilegiado e o nível 3 o menos privilegiado. Eles aparecem 
na Figura 4-29. A cada instante, um programa em execução está em certo nível, indicado por 
um campo de 2 bits em seu PSW. Cada segmento no sistema também tem um nível. 

Contanto que um programa se restrinja a usar segmentos em seu próprio nível, tudo 
correrá bem. Tentativas de acessar dados em um nível mais alto são permitidas. Tentativas de 
acessar dados em um nível mais baixo são ilegais e causam interrupções (traps). Tentativas de 
chamar funções em um nível diferente (mais alto ou mais baixo) são permitidas, mas de ma- 
neira cuidadosamente controlada. Para fazer uma chamada em outro nível, a instrução CALL 
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Usos típicos 
dos níveis 


Nível 


Figura 4-29 Proteção no Pentium. 


deve conter um seletor, em vez de um endereço. Esse seletor designa um descritor chamado 
portão de chamada (call gate), o qual fornece o endereço da função a ser chamada. Assim, 
não é possível ir para o meio de um segmento de código arbitrário em um nível diferente. 
Apenas os pontos de entrada oficiais podem ser usados. 

Um uso típico desse mecanismo está sugerido na Figura 4-29. No nível 0, encontramos 
o núcleo do sistema operacional, o qual manipula a E/S, o gerenciamento de memória e 
outras coisas importantes. No nível 1, está presente a rotina de tratamento de chamada de sis- 
tema. Os programas de usuário podem chamar funções desse nível, para executar cnamadas 
de sistema, mas apenas uma lista de funções específica e protegida pode ser usada. O nível 
2 contém funções de biblioteca, possivelmente compartilhadas entre muitos programas em 
execução. Os programas de usuário podem chamar essas funções e ler seus dados, mas não 
podem modificá-las. Finalmente, os programas de usuário são executados no nível 3, que tem 
a menor proteção. 

As interrupções de software e de hardware usam um mecanismo semelhante ao portão 
de chamadas. Elas também referenciam descritores, em vez de endereços absolutos, e esses 
descritores apontam para funções específicas a serem executadas. O campo tipo da Figura 
4-26 distingue entre segmentos de código, segmentos de dados e os vários tipos de portões 


(gates). 


VISÃO GERAL DO GERENCIADOR DE PROCESSOS DO MINIX 3 


O gerenciamento de memória no MINIX 3 é simples: não se utiliza paginação. O gerencia- 
mento de memória do MINIX 3, conforme discutiremos aqui, também não faz swapping. O 
código do swapping está disponível no código-fonte completo e poderia ser ativado para fazer 
o MINIX 3 trabalhar em um sistema com limitação de memória física. Na prática, as memó- 
rias são tão grandes atualmente que raramente o swapping é necessário. 

Neste capítulo, estudaremos um servidor que executa em espaço de usuário designado 
como gerenciador de processos ou, abreviadamente, PM, de seu nome original, process 
manager. O gerenciador de processos manipula as chamadas de sistema relacionadas ao ge- 
renciamento de processos. Dessas, algumas estão intimamente envolvidas com o gerencia- 
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mento de memória. As chamadas fork, exec e brk estão nessa categoria. O gerenciamento de 
processos também inclui as chamadas de sistema relacionadas a sinais, configuração e con- 
sulta a propriedades dos processos, como informações de usuário e grupo, e contabilização 
de tempos de utilização da CPU. O gerenciador de processos do MINIX 3 também manipula 
a configuração e a consulta do relógio de tempo real. 

Às vezes, quando estivermos nos referindo à parte do gerenciador de processos que ma- 
nípula o gerenciamento da memória, vamos nos referir a ela como “gerenciador de memória”. 
É possível que em uma versão futura o gerenciamento de processos e o gerenciamento da 
memória sejam completamente separados, mas no MINIX 3 as duas funções estão mescladas 
em uma única. 

O PM mantém uma lista de lacunas ordenadas pelo endereço numérico de memória. 
Quando é necessária memória, seja devido a uma chamada de sistema fork ou exec, a lista de 
lacunas é pesquisada usando o algoritmo do primeiro que couber, em busca de uma lacuna 
que seja suficientemente grande. Sem swapping, o processo carregado em memória permane- 
ce exatamente no mesmo lugar durante sua execução inteira. Ele nunca é movido para outro 
lugar na memória nem sua área de memória alocada jamais aumenta ou diminui. 

Essa estratégia de gerenciamento de memória é um tanto incomum e merece alguma 
explicação. Ela foi originalmente derivada de três fatores: 


1. O desejo de manter o sistema fácil de ser entendido. 
2. A arquitetura da CPU original do IBM PC (um 8088 da Intel), 
3. O objetivo de tornar fácil portar o MINIX 3 para outro hardware, 


Primeiramente, como um sistema voltado para o ensino, evitar a complexidade era alta- 
mente desejável; uma listagem de código-fonte de quase 250 páginas foi considerada longa o 
bastante. Segundo, o sistema foi projetado para o IBM PC original, que nem tinha uma MMU; 
portanto, para começo de conversa, incluir paginação era impossível. Terceiro, como outros 
computadores de sua época também não possuíam MMUS, essa estratégia de gerenciamento 
de memória tornava mais fácil portar para o Macintosh, Atari, Amiga e outras máquinas. 

Naturalmente, poderia ser questionado se essa estratégia ainda faz sentido. O primeiro 
ponto ainda é válido, embora o sistema tenha definitivamente crescido com o passar dos 
anos. Entretanto, vários fatores novos também entram em questão agora. Os PCs modernos 
têm mais de 1000 vezes a quantidade da memória disponível no IBM PC original. Embora 
os programas sejam maiores, a maioria dos sistemas tem tanta memória que o swapping e a 
paginação dificilmente são necessários. Finalmente, até certo ponto, o MINIX 3 é destinado a 
sistemas de baixo poder de computação, como os sistemas embarcados. Hoje em dia, câma- 
ras digitais, DVD players, equipamentos estéreos, telefones celulares e outros produtos têm 
sistemas operacionais, mas certamente não suportam swapping nem paginação. O MINIX 3 
é uma escolha bastante razoável nesse mundo; portanto, o swapping e a paginação não têm 
alta prioridade. Contudo, existe um trabalho sendo realizado para ver o que pode ser feito 
em relação ao uso de memória virtual da maneira mais simples possível. O site web deve ser 
consultado para acompanhamento dos desenvolvimentos correntes. 

Também vale mencionar outra maneira pela qual a implementação do gerenciamento de 
memória no MINIX 3 difere da de muitos outros sistemas operacionais. O PM não faz parte 
do núcleo. Em vez disso, ele é um processo executado em espaço de usuário e se comunica 
com o núcleo por meio do mecanismo de mensagens padrão. A posição do PM aparece na 
Figura 2-29. 

Retirar o gerenciador de processos do núcleo é um exemplo da separação de política e 
mecanismo. As decisões sobre qual processo será carregado na memória, e onde (política), 
são tomadas pelo PM. A configuração real dos mapas de memória dos processos (mecanis- 


CAPÍTULO 4 e (GERENCIAMENTO DE MEMÓRIA 393 


4.7.1 


mo) é feita pela tarefa de sistema dentro do núcleo. Essa divisão torna relativamente fácil alte- 
rar a política de gerenciamento de memória (algoritmos etc.) sem ter de modificar as camadas 
inferiores do sistema operacional. 

A maior parte do código do PM é dedicada ao tratamento das chamadas de sistema do 
MINIX 3 que envolvem a criação de processos, principalmente fork e exec, em vez de apenas 
manipularem listas de processos e lacunas. Na próxima seção, veremos o layout da memória, 
e nas seções subsegiientes teremos um panorama de como as chamadas de sistema de geren- 
ciamento de processo são manipuladas pelo PM. 


Layout da memória 


Os programas do MINIX 3 podem ser compilados para usar os espaços I (instruções-código) 
e D (dados e pilha) combinados, nos quais todas as partes do processo (texto, dados e pilha) 
compartilham um bloco de memória alocado e liberado como uma unidade. Esse era o padrão 
da versão original do MINIX. No MINIX 3, entretanto, o padrão é compilar programas para 
usar espaços I e D separados. Por clareza, a alocação de memória do modelo combinado, 
mais simples, será discutida primeiro. Os processos que utilizam os espaços I e D separados 
podem usar a memória mais eficientemente, mas tirar proveito desse recurso complica as coi- 
sas. Vamos discutir as complicações depois que o caso mais simples for esboçado. 

No MINIX 3, a memória de operação é alocada em duas ocasiões. Primeiro, quando um 
processo executa um fork, é alocada a quantidade de memória necessária pelo filho. Segundo, 
quando um processo altera sua imagem de memória por meio da chamada de sistema exec, o 
espaço ocupado pela imagem antiga retorna como uma lacuna para a lista de regiões livres e 
memória é alocada para a nova imagem. A nova imagem pode estar em uma parte da memória 
diferente da memória liberada. Sua localização dependerá de onde for encontrada uma lacuna 
adequada. Memória também é liberada quando um processo termina, seja saindo ou sendo 
eliminado por um sinal. Há um terceiro caso: um processo de sistema pode solicitar memória 
para seu próprio uso; por exemplo, o driver de memória pode solicitar memória para o disco 
de RAM. Isso só pode acontecer durante a inicialização do sistema. 

A Figura 4-30 mostra a alocação de memória durante uma operação fork e uma ope- 
ração exec. Na Figura 4-30(a), vemos dois processos, A e B, na memória. Se A faz um fork, 
temos a situação da Figura 4-30(b). O filho é uma cópia exata de 4. Se agora o filho executa 
uma operação exec no arquivo C, a memória fica semelhante à Figura 4-30(c). A imagem do 
filho é substituída por C. 


z7? 
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A 
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Figura 4-30 Alocação de memória. (a) Originalmente. (b) Após uma operação fork. (c) Após 
o filho executar uma operação exec. As regiões sombreadas representam memória não utiliza- 
da. O processo é um I&D comum. 
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Note que a memória antiga do filho é liberada antes que seja alocada a nova memória 
para C; portanto, C pode usar parte da memória anteriormente usada pelo filho. Desse modo, 
uma série de pares fork e exec (como no caso do shell usando pipes) pode resultar em todos 
os processos sendo adjacentes, sem nenhuma lacuna entre eles, supondo que exista um bloco 
grande de memória não alocada. As lacunas permaneceriam se a nova memória fosse alocada 
antes que a memória antiga tivesse sido liberada. 

Fazer isso dessa maneira não é simples. Considere a possível condição de erro pelo 
fato de não haver memória suficiente para executar uma operação exec. Deve ser feito um 
teste para saber se há memória suficiente para completar a operação, antes que a memória do 
filho seja liberada, para que este possa responder ao erro de algum modo. Isso significa que 
a memória do filho deve ser considerada como se fosse uma lacuna, enquanto ainda estiver 
sendo usada. 

Quando ocorre a alocação de memória, seja por fork ou pela chamada de sistema exec, 
uma determinada quantidade da memória total é dedicada para o novo processo. No primeiro 
caso, essa quantidade é idêntica à que o processo pai possui. No último caso, o PM aloca a 
quantidade especificada no cabeçalho do arquivo executado. Uma vez feita essa alocação, sob 
nenhuma condição o processo receberá mais memória. 

O que foi dito até aqui se aplica aos programas que foram compilados com os espaços I 
e D combinados. Os programas com espaços I e D separados tiram proveito de um modo de 
gerenciamento de memória melhorado, chamado texto compartilhado. Quando tal processo 
executa uma operação fork, é alocada apenas a quantidade de memória necessária para uma 
cópia dos dados e da pilha do novo processo. Tanto o pai como o filho compartilham o código 
executável que já está sendo usado pelo pai. Quando o novo processo executa uma operação 
exec, a tabela de processos é pesquisada para ver ser existe outro processo usando o código 
executável necessário. Se for encontrado um, será alocada nova memória apenas para os 
dados e para a pilha, e o texto que já está na memória será compartilhado. O texto comparti- 
lhado complica o término de um processo. Quando um processo termina, ele sempre libera a 
memória ocupada por seus dados e por sua pilha. Mas ele libera a memória ocupada por seu 
segmento de texto (código) somente depois que uma pesquisa da tabela de processos reve- 
la que nenhum outro processo corrente está compartilhando essa memória. Assim, para um 
processo pode ser alocada mais memória quando ele começa do que a que é liberada quando 
termina, caso tenha carregado seu próprio texto ao ser iniciado, mas esse texto esteja sendo 
compartilhado por um ou mais outros processos ao terminar. 

A Figura 4-31 mostra como um programa é armazenado como um arquivo de disco e 
como isso é transferido para o layout de memória interno de um processo do MINIX 3. O 
cabeçalho no arquivo de disco contém informações sobre os tamanhos das diferentes partes 
da imagem, assim como o tamanho total. No cabeçalho de um programa com espaços I e 
D comuns, um campo especifica o tamanho total das partes referentes ao texto (código) e 
aos dados; essas partes são copiadas diretamente na imagem da memória. A parte referente 
aos dados na imagem é ampliada pela quantidade especificada no campo bss do cabeçalho. 
Essa área de memória é zerada e é usada para dados estáticos não inicializados. A quanti- 
dade total de memória a ser alocada é especificada pelo campo total no cabeçalho. Se, por 
exemplo, um programa tem 4 KB de texto, 2 KB de dados mais uma área para o bss e 1 KB 
de pilha, e o cabeçalho diz para alocar 40 KB no total, a lacuna de memória não utilizada 
entre o segmento de dados e o segmento de pilha será de 33 KB. Um arquivo de programa 
no disco também pode conter uma tabela de símbolos. Isso serve para depuração e não é 
copiado na memória. 
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Figura 4-31 (a) Um programa conforme é armazenado em um arquivo de disco. (b) Layout 
interno da memória para um único processo. Nas duas partes da figura, o endereço de disco, 
ou de memória, mais baixo está na parte inferior e o endereço mais alto está na parte superior 
da figura. 


Se o programador souber que a memória total necessária para o crescimento combinado 
dos segmentos de dados e de pilha para o arquivo a.out será no máximo de 10 KB, poderá 
executar o comando 


chmem =10240 a.out 


que alterará o campo de cabeçalho de modo que, ao executar a operação exec, o PM alocará 
um espaço de 10240 bytes a mais do que a soma dos segmentos de texto e de dados iniciais. 
Para o exemplo anterior, será alocado um total de 16 KB nas chamadas exec subsegiientes do 
arquivo. Dessa quantidade, os 1 KB superiores serão usados para a pilha e 9 KB estarão na 
lacuna, onde poderão ser usados pelo crescimento da pilha, pela área de dados ou por ambos, 
conforme for necessário. 

Para um programa que utiliza espaços I e D separados (o que é indicado por um bit no 
cabeçalho, ativado pelo ligador), o campo de total no cabeçalho se aplica apenas aos espaços 
de dados e de pilha combinados. Para um programa com 4 KB de texto, 2 KB de dados, 1 
KB de pilha e um tamanho total de 64 KB, serão alocados 68 KB (4 KB de espaço de instru- 
ção, 64 KB de espaço de pilha e dados), deixando 61 KB para o segmento de dados e a pilha 
consumirem durante a execução. O limite do segmento de dados só pode ser movido pela 
chamada de sistema brk. Tudo que brk faz é verificar se o novo segmento de dados colide com 
o ponteiro de pilha corrente e, se não colidir, anotar a alteração em algumas tabelas internas. 
Isso é totalmente interno à memória originalmente alocada para o processo; nenhuma memó- 
ria adicional é alocada pelo sistema operacional. Se o novo segmento de dados colidir com a 
pilha, a chamada falhará. 

Este é um bom lugar para mencionar uma possível dificuldade semântica. Quando usa- 
mos a palavra “segmento”, nos referimos a uma área da memória definida pelo sistema ope- 
racional. Os processadores Intel têm um conjunto de registradores de segmento internos e 
tabelas de descritores de segmento que fornecem suporte de hardware para “segmentos”. 
O conceito de segmento dos projetistas de hardware da Intel é semelhante (mas nem sempre 
igual) ao dos segmentos usados e definidos pelo MINIX 3. Todas as referências a segmentos 
neste texto devem ser interpretadas como referências às áreas de memória delineadas pelas 
estruturas de dados do MINIX 3. Vamos nos referir explicitamente aos “registradores de seg- 
mento” ou aos “descritores de segmento”, quando falarmos sobre o hardware. 

Esse alerta pode ser generalizado. Os projetistas de hardware fregiientemente tentam 
fornecer suporte para os sistemas operacionais que esperam que sejam utilizados em suas 
máquinas e a terminologia usada para descrever registradores e outros aspectos da arquitetura 
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de um processador normalmente reflete uma idéia de como os recursos serão usados. Tais 
recursos frequentemente são úteis para o desenvolvedor de um sistema operacional, mas eles 
podem não serem usados da maneira prevista pelo projetista de hardware. Isso pode levar a 
mal-entendidos, quando a mesma palavra tem diferentes significados ao ser usada para des- 
crever um aspecto de um sistema operacional ou do hardware subjacente. 


Tratamento de mensagens 


Assim como todos os outros componentes do MINIX 3, o gerenciador de processos é orienta- 
do a troca de mensagens. Após a inicialização do sistema, o PM entra em seu laço principal, 
o qual consiste em esperar uma mensagem, executar a requisição nela contida e enviar uma 
resposta. 

Duas categorias de mensagens podem ser recebidas pelo gerenciador de processos. Para 
comunicação de alta prioridade entre o núcleo e os servidores do sistema, como o PM, é usa- 
da uma mensagem de notificação do sistema. Esses são casos especiais a serem discutidos 
na seção sobre implementação deste capítulo. A maioria das mensagens recebidas pelo ge- 
renciador de processos resulta de chamadas de sistema originadas por processos de usuário. 
Para essa categoria, a Figura 4-32 fornece a lista de tipos de mensagem válidos, parâmetros 
de entrada e valores enviados de volta na mensagem de resposta. 

Fork, exit, wait, waitpid, brk e exec são claramente intimamente relacionados com aloca- 
ção e liberação de memória. As chamadas kill, alarm e pause são todas relacionadas com si- 
nais, assim como sigaction, sigsuspend, sigpending, sigmask e sigreturn. Elas também podem 
afetar o que está na memória, pois quando um sinal elimina um processo, a memória usada 
por esse processo é liberada. As sete chamadas de get/set nada têm a ver com gerenciamento 
de memória, mas certamente estão relacionadas com gerenciamento de processos. Outras 
chamadas poderiam ficar no sistema de arquivos ou no PM, pois toda chamada de sistema é 
manipulada por um ou pelo outro. Elas foram colocadas aqui simplesmente por que o sistema 
de arquivos já estava bastante grande. As chamadas time, stime e times foram colocadas aqui 
por esse motivo, assim como ptrace, que é usada na depuração. 

Reboot tem efeitos em todo o sistema operacional, mas sua primeira tarefa é enviar 
sinais para terminar todos os processos de maneira controlada, de modo que o PM é um bom 
lugar para ela. O mesmo vale para svrctl, cujo uso mais importante é ativar ou desativar o 
swapping no PM. 

Talvez você tenha notado que as duas últimas chamadas mencionadas aqui, reboot e 
svrctl, não foram listadas na Figura 1-9. Isso também vale para as chamadas restantes da Fi- 
gura 4-32, getsysinfo, getprocnr, memalloc, memfree e getsetpriority. Nenhuma delas se des- 
tina a ser usada por processos de usuário normais e não fazem parte do padrão POSIX. Elas 
são fornecidas porque são necessárias em um sistema como o MINIX 3. Em um sistema com 
um núcleo monolítico, as operações fornecidas por essas chamadas poderiam ser providas 
por funções compiladas no núcleo. Mas, no MINIX 3, os componentes normalmente consi- 
derados como parte do sistema operacional são executados em espaço de usuário e chamadas 
de sistema adicionais são necessárias. Algumas delas fazem pouco mais do que implementar 
uma interface para uma chamada de núcleo, um termo que usamos para as chamadas que 
solicitam serviços do núcleo por intermédio da tarefa de sistema. 

Conforme mencionado no Capítulo 1, embora exista uma rotina de biblioteca sbrk, 
não há nenhuma chamada de sistema sbrk. A rotina de biblioteca calcula a quantidade de 
memória necessária somando o incremento ou decremento especificado como parâmetro ao 
tamanho corrente e faz uma chamada de brk para configurar o tamanho. Analogamente, não 
existem chamadas de sistema separadas para geteuid e getegid. As chamadas getuid e getgid 
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Tipo de mensagem 


Parâmetros de entrada 


Valor da resposta 


fork (nenhum) PID do filho, (para filho: 0) 

exit Status de saída (Nenhuma resposta se tiver êxito) 
wait (nenhum) Status 

waitpid Identificador de processo e flags Status 

brk Novo tamanho Novo tamanho 

exec Ponteiro para pilha inicial (Nenhuma resposta se tiver êxito) 


kill Identificador de processo e sinal Status 
alarm Número de segundos a esperar Tempo residual 
pause (nenhum) (Nenhuma resposta se tiver êxito) 
sigaction Número do sinal, ação, ação antiga Status 
sigsuspend Máscara de sinal (Nenhuma resposta se tiver êxito) 
sigpending (nenhum) Status 
sigprocmask Como, configuração, configuração Status 
antiga 
sigreturn Contexto Status 
getuid (nenhum) Uid, uid efetiva 
getgid (nenhum) Gid, gid efetiva 
getpid (nenhum) PID, PID do pai 
setuid Novo uid Status 
setgid Novo gid Status 
setsid Novo sid Grupo do processo 
getpgrp Novo gid Grupo do processo 
time Ponteiro para o lugar onde fica o tempo | Status 
corrente 
stime Ponteiro para o tempo corrente Status 
times Ponteiro para buffer de tempos de Tempo de funcionamento desde a 
processo e filho inicialização 
ptrace Requisição, PID, endereço, dados Status 
reboot Modo (suspende, reinicializa ou pânico) | (Nenhuma resposta se tiver êxito) 
svrctl Requisição, dados (depende da Status 
função) 
getsysinto Requisição, dados (depende da Status 
função) 
getprocnr (nenhum) Número do processo 
memalloc Tamanho, ponteiro para endereço Status 
memfree Tamanho, endereço Status 
getpriority Pid, tipo, valor Prioridade (valor de nice) 
setpriority Pid, tipo, valor Prioridade (valor de nice) 


gettimeofday 


(nenhum) 


Tempo, tempo de funcionamento 


Figura 4-32 Os tipos de mensagens, parâmetros de entrada e valores de resposta usados para comuni- 


cação com o PM. 


398 


SISTEMAS OPERACIONAIS 


4.7.3 


retornam os identificadores efetivo e real. Da mesma maneira, getpid retorna o PID do pro- 
cesso que fez a chamada e de seu pai. 

Uma estrutura de dados importante, usada para processamento de mensagens, é a tabela 
call vec, declarada em table.c. Ela contém ponteiros para as funções que manipulam os vá- 
rios tipos de mensagem. Quando uma mensagem chega no PM, o laço principal extrai o tipo 
da mensagem e o coloca na variável global call nr. Então, esse valor é usado como índice 
para call vec, para encontrar o ponteiro para a função que manipula a mensagem que aca- 
bou de chegar. Essa função executa a chamada de sistema. O valor que ela retorna é enviado 
de volta na mensagem de resposta ao processo origem para relatar o sucesso ou a falha da 
chamada. O mecanismo é semelhante à tabela de ponteiros para as rotinas de tratamento de 
chamada de sistema usadas na etapa 7 da Figura 1-16, somente que ele opera em espaço de 
usuário, em vez de operar no núcleo. 


Estruturas de dados e algoritmos do gerenciador de processos 


Duas estruturas de dados importantes são usadas pelo gerenciador de processos: a tabela de 
processos e a tabela de lacunas. Veremos agora cada uma delas por sua vez. 

Na Figura 2-4, vimos que alguns campos da tabela de processos são necessários para 
o núcleo, outros para o gerenciador de processos e ainda outros para o sistema de arquivos. 
No MINIX 3, cada uma dessas três partes do sistema operacional tem sua própria tabela de 
processos, contendo apenas os campos que ela precisa. Com algumas exceções, as entradas 
correspondem exatamente, para manter as coisas simples. Assim, a entrada k da tabela do PM 
se refere ao mesmo processo que a entrada k da tabela do sistema de arquivos. Quando um 
processo é criado ou destruído, todas as três partes atualizam suas tabelas para refletir a nova 
situação, para mantê-las sincronizadas. 

As exceções são os processos que não são conhecidos fora do núcleo, ou porque são 
compilados no núcleo, como as tarefas CLOCK e SYSTEM, ou porque são de suporte como 
IDLE e KERNEL. Na tabela de processos do núcleo, suas entradas são designadas por nú- 
meros negativos. Essas entradas não existem nas tabelas de processos do gerenciador de pro- 
cessos e do sistema de arquivos. Assim, rigorosamente falando, o que foi dito anteriormente 
sobre a entrada k nas tabelas é verdade para k igual ou maior do que zero. 


Processos na memória 


A tabela de processos do PM é chamada mproc e sua definição é dada em src/servers/pm/ 
mproc.h. Ela contém todos os campos relacionados à alocação de memória de um processo, 
assim como alguns itens adicionais. O campo mais importante é o array mp seg, que tem três 
entradas, para os segmentos de texto, de dados e de pilha respectivamente. Cada entrada é 
uma estrutura contendo o endereço virtual, o endereço físico e o tamanho do segmento, todos 
medidos em clicks, em vez de bytes. O tamanho de um click depende da implementação. Nas 
primeiras versões do MINIX ele era de 256 bytes. Para o MINIX 3 ele tem 1024 bytes. Todos 
os segmentos devem começar em um limite de click e ocupar um número inteiro de clicks. 

O método usado para registrar a alocação de memória está mostrado na Figura 4-33. 
Nessa figura, temos um processo com 3 KB de texto, 4 KB de dados, uma lacuna de 1 KB e, 
em seguida, uma pilha de 2 KB, para uma alocação de memória total de 10 KB. Na Figura 
4-33(b), vemos como são os campos de endereço virtual, físico e de comprimento de cada 
um dos três segmentos, supondo que o processo não tenha espaços I e D separados. Nesse 
modelo, o segmento de texto está sempre vazio e o segmento de dados contém tanto texto 
como dados. Quando um processo referenciar o endereço virtual 0, seja para ir para ele ou 
para lê-lo (isto é, como espaço de instrução ou como espaço de dados), será usado o endereço 
físico 0x32000 (em decimal, 200K). Esse endereço está no click Oxc8. 
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Figura 4-33 (a) Um processo na memória. (b) Sua representação de memória para espaços I 
e D combinados. (c) Sua representação de memória para espaços I e D separados. 


Note que o endereço virtual em que a pilha começa depende inicialmente da quantidade 
total de memória alocada para o processo. Se o comando chmem fosse usado para modificar 
o cabeçalho do arquivo, para fornecer uma área de alocação dinâmica maior (uma lacuna 
maior entre os segmentos de dados e de pilha), na próxima vez que o arquivo fosse executado, 
a pilha começaria em um endereço virtual mais alto. Se a pilha ficar um click mais longa, a 
entrada da pilha deverá mudar da tupla (0x8, OxdO, 0x2) para a tupla (0x7, Oxcf, 0x3). Note 
que, neste exemplo, o crescimento da pilha por um click reduziria a lacuna a nada, caso não 
houvesse nenhum aumento da alocação de memória total. 

O hardware do 8088 não tem interrupção de estouro de limite de pilha e o MINIX de- 
fine a pilha de maneira que em processadores de 32 bits não seja disparada essa interrupção 
até que a pilha já tenha sobrescrito o segmento de dados. Assim, essa alteração não será feita 
até a próxima chamada de sistema brk, ponto em que o sistema operacional lerá o SP (Stack 
Pointer) explicitamente e recalculará as entradas do segmento. Em uma máquina com inter- 
rupção de limite de pilha, a entrada do segmento de pilha poderia ser atualizada assim que a 
pilha ultrapassasse seu segmento. Isso não é feito pelo MINIX 3 em processadores Intel de 32 
bits, por razões que discutiremos agora. 

Mencionamos anteriormente que os esforços dos projetistas de hardware podem nem 
sempre produzir exatamente o que o projetista de software precisa. Mesmo no modo prote- 
gido em um Pentium, o MINIX 3 não interrompe quando a pilha ultrapassa seu segmento. 
Embora, no modo protegido, o hardware Intel detecte tentativas de acessar a memória fora 
de um segmento (conforme definido por um descritor de segmento como o da Figura 4-26), 
no MINIX 3 o descritor de segmento de dados e o descritor de segmento de pilha são sempre 
idênticos. Os segmentos de dados e de pilha do MINIX 3 usam parte desse espaço e, assim, 
um deles ou ambos podem expandir-se na lacuna entre eles. Entretanto, apenas o MINIX 3 
pode gerenciar isso. A CPU não tem meios de detectar erros envolvendo a lacuna, pois no 
que diz respeito ao hardware, a lacuna é uma parte válida da área de dados e da área de pilha. 
É claro que o hardware pode detectar um erro muito grande, como uma tentativa de acessar 
memória fora da área de dados, lacuna e pilha combinadas. Isso protegerá um processo dos 
erros de outro processo, mas não é suficiente para proteger um processo de si mesmo. 
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Uma decisão de projeto foi tomada aqui. Reconhecemos que pode se argumentar a fa- 
vor de abandonar o segmento compartilhado definido pelo hardware e permitir ao MINIX 3 
alocar dinamicamente a área de lacuna. A alternativa, usar o hardware para definir segmentos 
de pilha e de dados não sobrepostos, ofereceria bem mais segurança para certos erros, mas 
faria o MINIX 3 utilizar mais memória. O código-fonte está disponível para quem quiser 
avaliar a outra estratégia. 

A Figura 4-33(c) mostra as entradas de segmento para o layout de memória da Figura 
4-33(a), para espaços I e D separados. Aqui, os segmentos de texto e de dados têm tamanho 
diferente de zero. O array mp seg mostrado na Figura 4-33(b) ou (c) é usado principalmente 
para fazer o mapeamento de endereços virtuais em endereços de memória físicos. Dado um 
endereço virtual e o espaço ao qual ele pertence, é simples ver se o endereço virtual é válido 
ou não (isto é, se cai dentro de um segmento) e, se for válido, qual é o endereço físico corres- 
pondente. A função de núcleo umap local realiza esse mapeamento para as tarefas de E/S e 
de cópia em espaço de usuário (e dele), por exemplo. 
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Figura 4-34 (a) O mapa de memória de um processo com espaços I e D separados, como 
na figura anterior. (b) O layout na memória após um segundo processo começar, executando 
a mesma imagem de programa com texto compartilhado. (c) O mapa de memória do segundo 
processo. 


Texto compartilhado 


O conteúdo das áreas de dados e de pilha pertencentes a um processo pode mudar à medida 
que o processo executa, mas o texto (código) não muda. E comum vários processos estarem 
executando cópias do mesmo programa; por exemplo, vários usuários podem estar execu- 
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tando o mesmo shell. A eficiência da memória melhora com o uso de texto compartilhado. 
Quando a operação exec está para instanciar um processo, ela abre o arquivo que contém a 
imagem de disco do programa a ser carregado e lê seu cabeçalho. Se o processo usa espaços I 
e D separados, é feita uma pesquisa dos campos mp dev, mp inoemp ctime em cada entrada 
de mproc. Esses campos contêm os números de dispositivo e i-nodes e os estados das imagens 
que estão sendo executadas por outros processos. Se for encontrado na memória um processo 
executando o mesmo programa que está para ser carregado, não há necessidade de alocar 
memória para outra cópia do texto. Em vez disso, a parte mp seg[7T] do mapa de memória 
do novo processo é inicializada de forma a apontar para o mesmo lugar onde o segmento de 
texto já está carregado e apenas as partes dos dados e da pilha são configuradas em uma nova 
alocação de memória. Isso está mostrado na Figura 4-34. Se o programa usa espaços I e D 
combinados, ou nenhuma correspondência é encontrada, a memória é alocada como se vê na 
Figura 4-33 e o texto e os dados do novo processo são copiados do disco. 

Além das informações de segmento, mproc também contém informações adicionais 
sobre o processo. Isso inclui a ID do processo (PID) em si e de seu pai, os UIDs e GIDs (reais 
e efetivos), informações sobre sinais e o status de saída, caso o processo já tenha terminado, 
mas seu pai ainda não executou uma operação wait para ele. Além disso, em mproc existem 
campos para um temporizador para sigalarm e para o tempo acumulado do usuário e do 
sistema usado pelos processos filhos. O núcleo era responsável por esses itens nas versões 
anteriores do MINIX, mas a responsabilidade por eles foi transferida para o gerenciador de 
processos no MINIX 3. 


A lista de lacunas 


A outra estrutura de dados importante do gerenciador de processos é a tabela de lacunas, 
hole, definida em src/servers/pm/alloc.c, que lista cada lacuna presente na memória pela or- 
dem ascendente do endereço de memória. Os espaços entre os segmentos de dados e de pilha 
não são considerados lacunas; eles já foram alocados para processos. Consegiientemente, eles 
não estão contidos na lista de lacunas livres. Cada entrada da lista de lacunas tem três cam- 
pos: o endereço de base da lacuna, em clicks; o tamanho da lacuna, também em clicks; e um 
ponteiro para a próxima entrada na lista. A lista é de encadeada simples, de modo que é fácil 
encontrar a próxima lacuna a partir de qualquer lacuna dada, mas para encontrar a lacuna 
anterior, você precisa pesquisar a lista inteira desde o início, até chegar à lacuna dada. Devido 
às limitações de espaço, alloc.c não foi incluída na listagem impressa, embora esteja no CD- 
ROM. Mas o código que define a lista de lacunas é simples e está mostrado na Figura 4-35. 


PRIVATE struct hole ( 
struct hole *h next; /* ponteiro para a próxima entrada na lista */ 
phys clicks h base; /* onde a lacuna começa? */ 
phys clicks h len; /* qual é o tamanho da lacuna? */ 


} hole[NR_HOLES]; 


Figura 4-35 A lista de lacunas é um array de struct hole. 


O motivo para registrar tudo sobre segmentos e lacunas em clicks, em vez de usar bytes, 
é simples: é muito mais eficiente. No modo de 16 bits, são usados inteiros de 16 bits para 
registrar endereços de memória; portanto, com clicks de 1024 bytes, até 64 MB de memória 
podem ser suportados. Em 32 bits, os campos de endereço podem se referir a até 22 x2" = 
Je bytes, o que dá 4 terabytes (4096 gigabytes). 

As principais operações na lista de lacunas são a alocação de uma parte da memória de 
determinado tamanho e o retorno de uma alocação existente. Para alocar memória, a lista de 
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lacunas é pesquisada, a partir da lacuna com o endereço mais baixo, até que seja encontrada 
uma lacuna suficientemente grande (algoritmo do primeiro que couber). Então, o segmento 
é alocado e a lacuna é atualizada diminuindo-se a quantidade necessária ao segmento ou, 
no caso raro da lacuna ser do tamanho exato, removendo-a da lista. Esse esquema é rápi- 
do e simples, mas sofre de uma pequena fragmentação interna (até 1023 bytes podem ser 
desperdiçados no último click, pois é sempre alocado um múltiplo inteiro de clicks) e de 
fragmentação externa. 

Quando um processo termina é feito uma “limpeza”, sua memória de dados e de pilha 
é retornada para a lista de lacunas livres. Se ele utiliza I e D combinados, isso libera toda 
a sua memória, pois esses programas nunca têm uma alocação de memória separada para 
texto. Se o programa usa I e D separados, e uma pesquisa da tabela de processos identificar 
que nenhum outro processo está compartilhando o texto, a área de memória do texto também 
será liberada. Uma vez que, com texto compartilhado, as regiões de texto e dados não são 
necessariamente adjacentes, duas regiões de memória podem ser liberadas. Para cada região 
retornada, se um dos vizinhos dessa região, ou ambos, forem lacunas, eles serão fusiona- 
dos, de modo que nunca ocorrem lacunas adjacentes. Assim, o número, a localização e os 
tamanhos das lacunas variam continuamente durante a operação do sistema. Quando todos 
os processos de usuário tiverem terminado, toda a memória disponível estará pronta para 
alocação mais uma vez. Entretanto, essa não é necessariamente uma única lacuna, pois a me- 
mória física pode ser intercalada por regiões não usadas pelo sistema operacional, como nos 
sistemas compatíveis com as máquinas IBM, onde a memória somente de leitura (ROM) e a 
memória reservada para transferências de E/S separam a memória abaixo do endereço 640K, 
da memória acima de 1 MB. 


As chamadas de sistema FORK, EXIT e WAIT 


Quando processos são criados ou destruídos, memória deve ser alocada ou liberada. Além 
disso, a tabela de processos deve ser atualizada, incluindo as partes mantidas pelo núcleo e 
pelo sistema de arquivos. O gerenciador de processos coordena toda essa atividade. A criação 
de processos é feita por fork e executada na série de etapas mostradas na Figura 4-36. 


1. Verificar se a tabela de processos está plena. 
2. Tentar alocar memória para os dados e para a pilha do filho. 


3. Copiar os dados e a pilha do pai na memória do filho. 


4. Encontrar uma entrada de processo livre e copiar nela a entrada do pai. 


5. Inserir o mapa de memória do filho na tabela de processos. 
6. Escolher um PID para o filho. 
7. Informar o núcleo e o sistema de arquivos sobre o filho. 


8. Apresentar o mapa de memória do filho para o núcleo. 


9. Enviar mensagens de resposta para o pai e para o filho. 


Figura 4-36 As etapas exigidas para executar a chamada de sistema fork. 


É difícil e inconveniente parar uma chamada de fork no meio do caminho; portanto, o 
PM mantém o tempo todo uma contagem do número de processos correntemente existentes 
para ver facilmente se uma entrada está disponível na tabela de processos. Se a tabela não 
estiver cheia, é feita uma tentativa de alocar memória para o filho. Se o programa usa espaços 
Ie D separados, é solicitada apenas memória suficiente para as novas alocações de dados e 
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de pilha. Se essa etapa também for bem-sucedida, é garantido o sucesso da operação fork. 
Então, a memória recentemente alocada é preenchida, uma entrada de processo é localizada e 
preenchida, um PID é escolhido e as outras partes do sistema são informadas de que um novo 
processo foi criado. 

Um processo termina completamente quando dois eventos tiverem acontecido: (1) o 
próprio processo saiu (ou foi eliminado por um sinal) e (2) seu pai executou uma chamada 
de sistema wait para descobrir o que aconteceu. Um processo que saiu ou foi eliminado, mas 
cujo pai (ainda) não executou uma operação wait para ele, entra em uma espécie de animação 
suspensa, às vezes conhecida como estado zumbi. Ele é impedido de ser escalonado e seu 
temporizador de alarme é desligado (se estava ligado), mas não é removido da tabela de pro- 
cessos. Sua memória é liberada. O estado zumbi é temporário e raramente dura muito tempo. 
Quando o pai finalmente executa a operação wait, a entrada da tabela de processos é liberada 
e o sistema de arquivos e o núcleo são informados. 

Um problema surge se o pai de um processo que está terminando já foi eliminado. 
Se nenhuma ação especial fosse executada, o processo que está saindo permaneceria como 
zumbi para sempre. Em vez disso, as tabelas são alteradas para torná-lo filho do processo 
init. Quando o sistema inicializa, init lê o arquivo /etc/ttytab para obter uma lista de todos os 
terminais e, então, cria um processo login para tratar de cada um. Em seguida, ele é bloque- 
ado, esperando que os processos terminem. Dessa maneira, zumbis órfãos são eliminados 
rapidamente. 


A chamada de sistema EXEC 


Quando um comando é digitado no terminal, o shell cria um novo processo, o qual executa 
então o comando solicitado. Seria possível ter uma única chamada de sistema para executar 
as operações fork e exec simultaneamente, mas elas foram fornecidas como duas chamadas 
distintas por um motivo muito bom: facilitar a implementação de redirecionamento de E/S. 
Quando o shell cria um outro processo, se a entrada padrão é redirecionada, o filho a fecha 
e, então, abre uma nova entrada padrão, antes de executar o comando. Dessa maneira, o pro- 
cesso recentemente iniciado herda a entrada padrão redirecionada. A saída padrão é tratada 
da mesma maneira. 

Exec é a chamada de sistema mais complexa no MINIX 3. Ela precisa substituir a 
imagem de memória corrente por uma nova, incluindo a configuração de uma nova pilha. 
Evidentemente, a nova imagem deve ser um arquivo binário executável. Um arquivo exe- 
cutável também pode ser um script, que deve ser interpretado por outro programa, como o 
shell ou perl. Nesse caso, o arquivo cuja imagem deve ser colocada na memória é o binário 
do interpretador, com o nome do script como argumento. Nesta seção, discutimos o caso 
simples de uma chamada exec que se refere a um binário executável. Posteriormente, quando 
discutirmos a implementação de exec, será descrito o processamento adicional exigido para 
executar um script. 

Exec executa sua tarefa em uma série de etapas, como se vê na Figura 4-37. 

Cada etapa, por sua vez, consiste em etapas menores, algumas das quais podem falhar. 
Por exemplo, pode não haver memória suficiente disponível. A ordem na qual os testes são 
feitos foi cuidadosamente escolhida para garantir que a imagem de memória antiga não seja 
liberada até que seja certo que a operação exec será bem-sucedida, para evitar a situação 
embaraçosa de não ser possível configurar uma nova imagem de memória e também não ter 
a antiga para restaurar. Normalmente, exec não retorna, mas se falhar, o processo que fez a 
chamada deverá obter o controle novamente, com uma indicação de erro. 
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1. Verificar permissões—o arquivo é executável? 
2. Ler o cabeçalho para obter os tamanhos de segmento e total. 


3. Buscar os argumentos e o ambiente do processo que fez a chamada. 


4. Alocar nova memória e liberar a memória antiga desnecessária. 


5. Copiar a pilha na nova imagem de memória. 


6. Copiar o segmento de dados (e, possivelmente, o de texto) na nova imagem 
de memória. 


7. Verificar e manipular os bits setuid, setgid. 


8. Corrigir a entrada da tabela de processos. 


9. Informar o núcleo de que, agora, o processo é executável. 


Figura 4-37 As etapas exigidas para executar a chamada de sistema exec. 


Algumas etapas da Figura 4-37 merecem mais comentários. Primeiro, há a questão de 
haver espaço suficiente ou não. Após determinar a quantidade de memória necessária, o que 
exige determinar se a memória de texto de outro processo pode ser compartilhada, a lista de 
lacunas é pesquisada para verificar se há memória física suficiente antes de liberar a memória 
antiga. Se a memória antiga fosse liberada primeiro e não houvesse memória suficiente, seria 
difícil reaver a imagem antiga novamente e estaríamos em apuros. 

Entretanto, esse teste é demasiadamente restrito. Às vezes, ele rejeita chamadas de exec 
que, na verdade, poderiam ser bem-sucedidas. Suponha, por exemplo, que o processo que 
está fazendo a chamada de exec ocupe 20 KB e seu texto não seja compartilhado por nenhum 
outro processo. Suponha ainda que exista uma lacuna de 30 KB disponível e que a nova ima- 
gem exija 50 KB. Fazendo o teste antes de liberar, descobriremos que apenas 30 KB estão 
disponíveis e rejeitamos a chamada. Se tivéssemos liberado primeiro, poderíamos ter êxito, 
dependendo de a nova lacuna de 20 KB ser adjacente ou não e, assim, ser fusionada com a 
lacuna de 30 KB. Uma implementação mais sofisticada poderia tratar dessa situação de forma 
um pouco melhor. 

Outro possível aprimoramento seria procurar duas lacunas, uma para o segmento de 
texto e outra para o segmento de dados, caso o processo a executar a operação exec use espa- 
ços I e D separados. Os segmentos não precisam ser adjacentes. 

Um problema mais sutil é se o arquivo executável cabe no espaço de endereçamento 
virtual. O problema é que a memória é alocada não em bytes, mas em clicks de 1024 bytes. 
Cada click deve pertencer a um único segmento e pode não ser, por exemplo, metade dados, 
metade pilha, pois a gerência da memória inteira é feita em clicks. 

Para ver como essa restrição pode causar problemas, note que o espaço de endereça- 
mento nos processadores Intel de 16 bits (8086 e 80286) é limitado a 64 KB, o qual, com 
um tamanho de click de 1024 permite a existência de 64 clicks. Suponha que um programa 
que use espaços I e D separados tenha 40.000 bytes de texto, 32.770 bytes de dados e 32.760 
bytes de pilha. O segmento de dados ocupa 33 clicks, embora apenas 2 bytes do último click 
seja usado; apesar disso, o click inteiro deve ser dedicado ao segmento de dados. O segmento 
de pilha tem 32 clicks. Juntos, eles ultrapassam os 64 clicks e, portanto, não podem coexistir, 
mesmo que o número de bytes necessários caiba (no limite) no espaço de endereçamento vir- 
tual. Teoricamente, esse problema existe em todas as máquinas cujo tamanho de click é maior 
do que 1 byte, mas na prática ele raramente ocorre nos processadores da classe Pentium, pois 
eles permitem segmentos grandes (de 4 GB). Infelizmente, o código tem que verificar esse 
caso. Um sistema que não verifica as condições raras, mas possíveis, provavelmente falhará 
de uma maneira inesperada, se uma delas vier a ocorrer. 
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Outro problema importante é o modo como a pilha inicial é configurada. A chamada de 
biblioteca normalmente usada para ativar exec com argumentos e um ambiente é 


execve(name, argv, envp); 


onde name é um ponteiro para o nome do arquivo a ser executado, argv é um ponteiro para 
um array de ponteiros, cada um apontando para um argumento, e envp é um ponteiro para um 
array de ponteiros, onde cada um apontando para uma string de ambiente. 

Seria muito fácil implementar exec apenas colocando os três ponteiros na mensagem 
para o PM e deixando que ele buscasse o nome de arquivo e os dois arrays sozinho. Então, 
ele teria que buscar cada argumento e cada string, um por vez. Fazer isso dessa maneira exige 
pelo menos uma mensagem para a tarefa de sistema por argumento ou string e, provavelmen- 
te, mais, pois o PM não tem meios de saber antecipadamente o tamanho de cada um. 

Para evitar a sobrecarga de múltiplas mensagens para ler todas essas partes, foi esco- 
lhida uma estratégia completamente diferente. A função de biblioteca execve constrói a pilha 
inicial inteira dentro de si mesma e passa seu endereço de base e seu tamanho para o PM. 
Construir a nova pilha dentro do espaço de usuário é altamente eficiente, pois as referências 
aos argumentos e strings são apenas referências de memória locais e não referências para um 
espaço de endereçamento diferente. 

Para tornar esse mecanismo mais claro, considere um exemplo. Quando um usuário 
digita 


Is —l f.c g.c 
no shell, este interpreta o comando e então faz a chamada 
execve(“/bin/ls”, argv, envp); 


para a função de biblioteca. O conteúdo dos dois arrays de ponteiros aparece na Figura 
4-38(a). Agora, a função execve, dentro do espaço de endereçamento do shell, constrói a 
pilha inicial, como se vê na Figura 4-38(b). Finalmente, essa pilha é copiada intacta no PM, 
durante o processamento da chamada de exec. 

Quando a pilha for finalmente copiada no processo de usuário, ela não será colocada no 
endereço virtual 0. Em vez disso, será colocada no final da alocação de memória, conforme 
determinado pelo campo de tamanho de memória total no cabeçalho do arquivo executável. 
Como exemplo, vamos supor arbitrariamente que o tamanho total seja de 8192 bytes, de 
modo que o último byte disponível para o programa está no endereço 8191. Cabe ao PM 
reposicionar os ponteiros dentro da pilha para que, quando depositada no novo endereço, a 
pilha seja semelhante à Figura 4-38(c). 

Quando a chamada exec terminar e o programa começar a ser executado, a pilha será 
mesmo exatamente como a Figura 4-38(c), com o ponteiro de pilha tendo o valor 8136. En- 
tretanto, outro problema ainda precisa ser resolvido. O programa principal do arquivo execu- 
tado provavelmente é declarado como segue: 


main(argc, argv, envp); 


No que diz respeito ao compilador C, main é apenas outra função. Ele não sabe que 
main é especial; portanto, compila o código para acessar os três parâmetros, supondo que 
eles serão passados na pilha de acordo com a convenção de chamada padrão da linguagem 
C, com o último parâmetro primeiro. Com um inteiro e dois ponteiros, espera-se que os três 
parâmetros ocupem as três palavras imediatamente anteriores ao endereço de retorno. É claro 
que a pilha da Figura 4-38(c) não se parece nada com isso. 
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Array de 
ambiente 


Array de 
argumentos 


(a) 


Figura 4-38 (a) Os arrays passados para execve. (b) A pilha construída por execve. (c) A 
pilha após a realocação feita pelo PM. (d) A pilha conforme ela aparece para main no início 
da execução. 


A solução é o programa não começar com o main. Em vez disso, uma pequena rotina 
em linguagem assembly, chamada função C run-time, start-off ou crtso, é sempre ligada no 
endereço de texto 0, de modo que ela recebe o controle primeiro. Sua tarefa é colocar mais 
três palavras na pilha e, então, chamar main de forma padrão. Isso resulta na pilha da Figura 
4-38(d) no momento em que main começa a executar. Assim, main é enganada, pensando 
que foi chamada da maneira normal (na verdade, não se trata realmente de um truque; ela é 
chamada dessa maneira). 

Se o programador esquecer de chamar exit no final de main, o controle voltará para a 
rotina C run-time, start-off, quando main tiver terminado. Novamente, o compilador apenas 
vê main como uma função normal e gera o código usual para retornar dela após a última 
instrução. Assim, main retorna para quem a chamou, a rotina C run-time, start-off, a qual, 
então, chama exit. A maior parte do código de 32 bits de crtso aparece na Figura 4-39. Os 
comentários devem tornar seu funcionamento mais claro. Foram omitidos a inicialização do 
ambiente, se não for definida pelo programador, o código que define os valores dos registra- 
dores que são postos na pilha e algumas linhas que ativam um flag indicativo da presença 
ou não de um co-processador em ponto flutuante. O código-fonte completo está no arquivo 
src/lib/i386/rts/crtso.s. 


A chamada de sistema BRK 


As funções de biblioteca brk e sbrk são usadas para ajustar o limite superior do segmento de 
dados. A primeira recebe um tamanho absoluto (em bytes) e chama brk. A segunda recebe 


CAPÍTULO 4 e (GERENCIAMENTO DE MEMÓRIA 407 


4.7.7 


push ecx ! empilha environ 

push edx ! empilha argv 

push eax ! empilha argc 

call main ! main(argc, argv, envp) 

push eax ! empilha status de saída 

call. exit 

hit !força uma interrupção se a saída falhar 


Figura 4-39 A parte principal de crtso, a rotina C run-time, start-off. 


um incremento positivo ou negativo para o tamanho corrente, calcula o novo tamanho do seg- 
mento de dados e, então, chama brk. Na verdade, não há nenhuma chamada de sistema sbrk. 

Uma questão interessante é: “como sbrk monitora o tamanho corrente para poder cal- 
cular o novo tamanho?” A resposta é que uma variável, brksize, sempre contém o tamanho 
corrente para que shrk possa encontrá-lo. Essa variável é inicializada com um símbolo gera- 
do pelo compilador, que fornece o tamanho inicial do texto mais os dados (I e D combina- 
dos) ou apenas dos dados (I e D separados). O nome e, na verdade, a própria existência desse 
símbolo depende do compilador e, assim, sua definição não será encontrada em nenhum 
dos arquivos de cabeçalho nos diretórios de arquivo-fonte. Ele é definido na biblioteca, no 
arquivo brksize.s. Exatamente onde ele será encontrado depende do sistema, mas estará no 
mesmo diretório que crtso.s. 

Executar brk é fácil para o gerenciador de processos. Basta verificar se tudo ainda cabe 
no espaço de endereçamento, ajustar as tabelas e informar o núcleo. 


Tratamento de sinais 


No Capítulo 1, os sinais foram descritos como um mecanismo para transmitir informações 
para um processo que não está necessariamente esperando por uma entrada de dados. Existe 
um conjunto de sinais definido e cada sinal tem uma ação padrão — eliminar o processo para 
o qual foi direcionado ou ser ignorado. Seria fácil entender e implementar o processamento 
dos sinais, se essas fossem as únicas alternativas. Entretanto, os processos podem usar cha- 
madas de sistema para alterar essas respostas. Um processo pode pedir para que qualquer 
sinal (exceto o sinal especial sigkill) seja ignorado. Além disso, um processo de usuário pode 
se preparar para capturar um sinal, solicitando que uma função de tratamento de sinal, 
interna ao processo, seja executada no lugar da ação padrão. Isso para qualquer sinal (exceto, 
novamente, quanto a sigkill). Assim, para o programador, quando o sistema operacional trata 
com sinais, parece que são dois momentos distintos: uma fase de preparação, quando um 
processo pode modificar sua resposta para um futuro sinal, e uma fase de resposta, quando 
um sinal é gerado e sofre uma ação. A ação pode ser a execução de uma rotina de tratamento 
de sinal personalizada. Uma terceira fase também ocorre, como se vê na Figura 4-40. Quando 
uma rotina de tratamento escrita pelo usuário termina, uma chamada de sistema especial faz 
a limpeza e restaura a operação normal do processo sinalizado. O programador não precisa 
saber a respeito dessa terceira fase. Ele escreve uma rotina de tratamento de sinal exatamente 
como qualquer outra função. O sistema operacional cuida dos detalhes de chamar e terminar 
a rotina de tratamento e de gerenciar a pilha. 


Preparação: o código do programa se prepara para um possível sinal. 


Resposta: o sinal é recebido e a ação executada. 


Limpeza: restaura a operação normal do processo. 


Figura 4-40 Três fases do tratamento de sinais. 
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Na fase de preparação, existem várias chamadas de sistema que um processo pode exe- 
cutar a qualquer momento para alterar sua resposta a um sinal. A mais geral delas é sigaction, 
que pode especificar se o processo vai ignorar, capturar (substituindo a ação padrão pela 
execução de um código de tratamento de sinal definido pelo usuário, dentro do processo) ou 
restaurar a resposta padrão para algum sinal. Outra chamada de sistema, sigprocmask, pode 
bloquear um sinal, memorizando-o e acionando a ação somente quando, e se, o processo des- 
bloquear posteriormente esse sinal em particular. Essas chamadas podem ser feitas a qualquer 
momento, mesmo dentro de uma função de captura de sinal. No MINIX 3, a fase de prepa- 
ração de processamento de sinal é manipulada inteiramente pelo gerenciador de processos, 
pois as estruturas de dados necessárias estão todas na parte do PM da tabela de processos. 
Para cada processo existem diversas variáveis sigset t. Elas são mapas de bits nos quais cada 
sinal possível é representado por um bit. Uma dessas variáveis define um conjunto de sinais 
a serem ignorados, outra define um conjunto de sinais a serem capturados e assim por diante. 
Para cada processo também existe um grupo de estruturas sigaction, uma para cada sinal. A 
estrutura está definida na Figura 4-41. Cada elemento da estrutura sigaction possui uma va- 
riável para conter o endereço de uma rotina de tratamento personalizada para esse sinal e uma 
variável sigset t adicional para mapear os sinais a serem bloqueados enquanto essa rotina de 
tratamento está em execução. O campo usado para o endereço da rotina de tratamento pode, 
em vez disso, conter valores especiais significando que o sinal deve ser ignorado ou tratado 
da maneira padrão definida para ele. 


struct sigaction ( 
- sSighandler tsa handler; /* SIG DFL, SIG IGN, SIG MESS, ou ponteiro para função */ 


sigset tsa mask; /* sinais a serem bloqueados durante a execução da rotina de 
tratamento */ 
intsa flags; /* flags especiais */ 


) 


Figura 4-41 A estrutura sigaction. 


Este é um bom lugar para mencionar que um processo de sistema, como o próprio ge- 
renciador de processos, não pode capturar sinais. Os processos de sistema usam um novo tipo 
de rotina de tratamento SIG MESS, que diz ao PM para que encaminhe um sinal por meio de 
uma mensagem de notificação SYS SIG. Nenhuma limpeza é necessária para sinais do tipo 
SIG MESS. 

Quando um sinal é gerado, várias partes do sistema MINIX 3 podem ser envolvidas. 
A resposta começa no PM, o qual descobre quais processos devem receber o sinal usando 
as estruturas de dados que acabamos de mencionar. Se o sinal é para ser capturado, ele deve 
ser enviado para o processo de destino. Isso exige salvar informações sobre o estado do pro- 
cesso, para que a execução normal possa ser retomada. As informações são armazenadas na 
pilha do processo sinalizado e deve ser feita uma verificação para determinar se há espaço 
suficiente na pilha. O PM faz essa verificação, pois isso está dentro de seu âmbito, e então 
chama a tarefa de sistema no núcleo para colocar as informações na pilha. A tarefa de sistema 
também manipula o contador de programa do processo, para que o processo possa executar o 
código da rotina de tratamento. Quando a rotina de tratamento termina, é feita uma chamada 
de sistema sigreturn. Por meio dessa chamada, o PM e o núcleo participam na restauração 
do contexto do sinal e dos registradores do processo sinalizado, para que ele possa retomar 
a execução normal. Se o sinal não for capturado, a ação padrão será executada, a qual pode 
envolver a chamada do sistema de arquivos para produzir um core dump (gravar a imagem de 
memória do processo em um arquivo para ser examinado posteriormente com um depurador), 
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assim como eliminar o processo, o que envolve o PM, o sistema de arquivos e o núcleo. O PM 
pode designar uma ou mais repetições dessas ações, pois um único sinal talvez precise ser 
enviado para um grupo de processos. 

Os sinais conhecidos pelo MINIX 3 são definidos em include/signal.h, um arquivo exigi- 
do pelo padrão POSIX. Eles estão listados na Figura 4-42. Todos os sinais obrigatórios do PO- 
SIX estão definidos no MINIX 3, mas nem todos os opcionais estão. Por exemplo, o POSIX 
exige vários sinais relacionados ao controle de tarefas, como a capacidade de colocar um pro- 
grama em execução em segundo plano e trazê-lo de volta. O MINIX 3 não suporta controle de 
tarefas, mas os programas que poderiam gerar esses sinais podem ser portados para o MINIX 
3. Se forem gerados, esses sinais serão ignorados. O controle de tarefas não foi implementado 
porque se destinava a fornecer uma maneira de iniciar a execução de um programa e, então, 
separar-se dele para permitir que o usuário fizesse outra coisa. No MINIX 3, após iniciar um 
programa, o usuário pode simplesmente pressionar ALT+F?2 para trocar para um novo terminal 
virtual para fazer outra coisa, enquanto o programa é executado. Os terminais virtuais são uma 
espécie de “primo pobre” dos sistemas de janelas, mas eliminam a necessidade do controle 
de tarefas e seus sinais, pelo menos se você estiver trabalhando no console local. O MINIX 3 
também define, para uso interno, alguns sinais que não são do POSIX e alguns sinônimos dos 
nomes POSIX para compatibilidade com código-fonte mais antigo. 

Em um sistema UNIX tradicional, os sinais podem ser gerados de duas maneiras: pela 
chamada de sistema kill e pelo núcleo. No MINIX 3, alguns processos do espaço de usuário 
fazem coisas que seriam feitas pelo núcleo em um sistema tradicional. A Figura 4-42 mostra 
todos os sinais conhecidos do MINIX 3 e suas origens. Sigint, sigquit e sigkill podem ser ini- 
ciados pelo pressionamento de combinações de tecla especiais no teclado. Sigalrm é geren- 
ciado pelo gerenciador de processos. Sigpipe é gerado pelo sistema de arquivos. O programa 
killpode ser usado para enviar qualquer sinal para qualquer processo. Alguns sinais do núcleo 
dependem de suporte do hardware. Por exemplo, os processadores 8086 e 8088 não suportam 
detecção de códigos de instrução inválidos, mas essa capacidade está disponível no 286 e 
superiores, que capturam uma tentativa de executar uma instrução inválida. Esse serviço é 
fornecido pelo hardware. O desenvolvedor do sistema operacional deve fornecer código para 
gerar um sinal em resposta à interrupção. Vimos, no Capítulo 2, que kernel/exception.c con- 
tém código para fazer exatamente isso para diversas condições diferentes. Assim, um sinal 
sigill será gerado em resposta a uma instrução inválida, quando o MINIX 3 for executado em 
um processador 286 ou superior; no 8088 original, ele nunca era visto. 

Apenas porque o hardware pode capturar determinada condição não significa que a 
capacidade pode ser usada completamente pelo desenvolvedor do sistema operacional. Por 
exemplo, vários tipos de violações da integridade da memória resultam em exceções em to- 
dos os processadores Intel a partir do 286. O código presente em kernel/exception.c trans- 
forma essas exceções em sinais sigsegv. Exceções separadas são geradas para violações dos 
limites do segmento de pilha definido pelo hardware e para outros segmentos, pois talvez 
elas precisem ser tratadas de formas diferentes. Entretanto, devido à maneira como o MINIX 
3 utiliza a memória, o hardware não consegue detectar todos os erros que podem ocorrer. O 
hardware define uma base e um limite para cada segmento. Os segmentos de pilha e de dados 
são combinados em um único segmento de hardware. A base do segmento de dados definido 
pelo hardware é a mesma base de segmento de dados do MINIX 3, mas o limite do segmento 
de dados definido pelo hardware é mais alto do que o limite que o MINIX 3 impõe no softwa- 
re. Em outras palavras, o hardware define o segmento de dados como a máxima quantidade 
de memória que o MINIX 3 poderia utilizar para dados, caso a pilha possa de alguma forma 
ser reduzida a nada. Analogamente, o hardware define a pilha como a quantidade máxima de 
memória que a pilha do MINIX 3 poderia usar caso a área de dados pudesse ser reduzida a 
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Sinal Descrição Gerado por 

SIGHUP Parada total Chamada de sistema KILL 

SIGINT Interrupção TTY 

SIGQUIT Encerramento TTY 

SIGILL Instrução inválida núcleo (*) 

SIGTRAP Geração de traços núcleo (M) 

SIGABRT Término anormal TIY 

SIGFPE Exceção de ponto flutuante núcleo (*) 

SIGKILL Eliminação (não pode ser capturado nem Chamada de sistema KILL 
ignorado) 

SIGUSR1 Sinal definido pelo usuário Não suportado 

SIGSEGV Violação de segmentação Núcleo (*) 

SIGUSR2 Sinal definido pelo usuário Não suportado 

SIGPIPE Escrita em um pipe sem ninguém para ler FS 

SIGALRM Alarme, tempo limite PM 

SIGTERM Sinal de software para encerramento de kill Chamada de sistema KILL 

SIGCHLD Processo filho terminou ou parou PM 

SIGCONT Continua se estiver parado Não suportado 

SIGSTOP Sinal de parada Não suportado 

SIGTSTP Sinal de parada interativo Não suportado 

SIGTTIN Processo de segundo plano quer ler Não suportado 

SIGTTOU Processo de segundo plano quer escrever Não suportado 

SIGKMESS | Mensagem do núcleo núcleo 

SIGKSIG Sinal do núcleo pendente núcleo 

SIGKSTOP | Desligamento do núcleo núcleo 


Figura 4-42 Sinais definidos pelo POSIX e pelo MINIX 3. Os indicados por (*) dependem 
de suporte do hardware. Os marcados com (M) não são definidos pelo POSIX, mas são defini- 
dos pelo MINIX 3 para compatibilidade com programas mais antigos. Os sinais do núcleo são 
gerados pelo núcleo e são específicos do MINIX 3, pois são usados para informar os processos 
de sistema sobre eventos. Vários nomes e sinônimos obsoletos não estão listados aqui. 


nada. Embora certas violações possam ser detectadas pelo hardware, o hardware não conse- 
gue detectar a violação de pilha mais provável, o crescimento da pilha na área de dados, pois, 
no que diz respeito aos registradores de hardware e às tabelas descritoras, a área de dados e a 
área da pilha se sobrepõem. 

Com certeza, um código poderia ser adicionado no núcleo para verificar o conteúdo 
do registrador de um processo, após cada vez que o processo tiver a chance de ser executado 
e gerar um sinal sigsegv ao detectar uma violação da integridade das áreas de dados ou de 
pilha definidas pelo MINIX 3. Não está claro se isso vale a pena; as interrupções de hardware 
podem capturar uma violação imediatamente. Uma verificação de software poderia não ter 
chance de fazer seu trabalho até que muitos milhares de instruções adicionais tivessem sido 
executadas e, nesse ponto, talvez uma rotina de tratamento de sinal pouco pudesse fazer para 
tentar a recuperação. 
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Qualquer que seja sua origem, o PM processa todos os sinais da mesma maneira. Para 
cada processo a ser sinalizado, são feitas várias verificações para ver se o sinal é viável. Um 
processo pode sinalizar outro, se o sinalizador for o superusuário ou se o UID real ou efetivo 
do sinalizador for igual ao UID real ou efetivo do processo sinalizado. Mas existem várias 
condições que podem impedir que um sinal seja enviado. Os zumbis não podem ser sinaliza- 
dos, por exemplo. Um processo não pode ser sinalizado se tiver chamado sigaction explici- 
tamente para ignorar o sinal ou sigprocmask para bloqueá-lo. Bloquear um sinal é diferente 
de ignorá-lo; a recepção de um sinal bloqueado é memorizada e ele é enviado quando e se o 
processo sinalizado remover o bloqueio. Finalmente, se seu espaço de pilha não for adequa- 
do, o processo sinalizado será eliminado. 

Se todas as condições forem satisfeitas, o sinal poderá ser enviado. Se o processo não 
tiver feito preparativos para o sinal ser capturado, nenhuma informação precisará ser passada 
para o processo. Nesse caso, o PM executará a ação padrão para o sinal, que normalmente é 
eliminar o processo, possivelmente produzindo também um core dump. Para alguns sinais, a 
ação padrão é ignorar o sinal. Os sinais marcados como “Não suportados”, na Figura 4-42, 
têm sua definição imposta pelo POSIX, mas são ignorados pelo MINIX 3, conforme permi- 
tido pelo padrão. 

Capturar um sinal significa executar código de tratamento de sinal personalizado, cujo 
endereço é armazenado em uma estrutura sigaction na tabela de processos. No Capítulo 2, 
vimos como o quadro de pilha dentro de sua entrada na tabela de processos recebe as infor- 
mações necessárias para reiniciar um processo quando ele é interrompido. Modificando-se o 
quadro de pilha de um processo a ser sinalizado, pode-se fazer com que, na próxima vez que 
o processo tiver permissão para executar, a rotina de tratamento de sinal seja executada. Mo- 
dificando-se a pilha do processo no espaço de usuário, pode-se fazer com que, quando a roti- 
na de tratamento de sinal terminar, seja feita a chamada de sistema sigreturn. Essa chamada 
de sistema nunca é feita por código escrito pelo usuário. Ela é executada depois que o núcleo 
coloca seu endereço na pilha, de maneira tal que este se torne o endereço de retorno extraído 
da pilha quando uma rotina de tratamento de sinal terminar. Sigreturn restaura o quadro de 
pilha original do processo sinalizado para que ele possa retomar a execução no ponto onde foi 
interrompido pelo sinal. 

Embora o último estágio do envio de um sinal seja executado pela tarefa de sistema, 
este é um bom lugar para resumir como isso é feito, pois os dados usados são passados para o 
núcleo a partir do PM. Capturar um sinal exige algo muito parecido com a troca de contexto 
que ocorre quando um processo é retirado da execução e outro é posto em execução, pois 
quando a rotina de tratamento termina, o processo deve ser capaz de continuar como se nada 
tivesse acontecido. Entretanto, na tabela de processos só há espaço para armazenar uma cópia 
do conteúdo de todos os registradores da CPU necessários para restaurar o processo ao seu 
estado original. A solução desse problema aparece na Figura 4-43. A parte (a) da figura é uma 
visão simplificada da pilha de um processo e parte de sua entrada na tabela de processos, ime- 
diatamente após ele ter sido retirado de execução depois de uma interrupção. No momento da 
suspensão, o conteúdo de todos os registradores da CPU é copiado na estrutura de quadro de 
pilha na entrada da tabela de processos do processo suspenso, na parte da tabela de processos 
referente ao núcleo. Essa será a situação no momento em que um sinal for gerado. Um sinal é 
gerado por um processo ou tarefa diferente do destinatário pretendido; portanto, o destinatá- 
rio não pode estar em execução nesse momento. 

Na preparação para tratar do sinal, o quadro de pilha da tabela de processos é copiado 
na pilha do processo receptor como uma estrutura sigcontext, preservando-o, portanto. Então, 
uma estrutura sigframe é colocada na pilha. Essa estrutura contém informações a serem usa- 
das por sigreturn depois que a rotina de tratamento terminar. Ela também contém o endereço 
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End. de retorno 


Variáveis locais 
(processos) 


End. de retorno 


Variáveis locais 
(processos) 


Quadro de pilha 


End. de retorno End. de retorno 


Variáveis locais 
(processos) 


Variáveis locais 
(processos) 


Quadro de pilha 


(registradores (registradores 
da CPU) da CPU) 
(original) (original) 
End. de End. de Pilha 
retorno 2 retorno 2 
Estrutura Local vars 
sigframe (Sigreturn) 
retorno 1 
Variáveis locais 
(rotina de 
tratamento) 
Quadro de pilha Quadro de pilha 
Quadro (registradores (registradores Quadro 
opra da CPU) da CPU) 'a piina Tabela de 
(registradores e : er . (registradores 
da CPU) (modificado, ip (modificado, ip da CPU) processos 


(original) 


= rotina de 
tratamento) 


= rotina de 


tratamento) (original) 


De volta Sigreturn em De volta 
ao normal execução ao normal 
(a) (b) (c) (d) 


Figura 4-43 A pilha de um processo (em cima) e seu quadro de pilha na tabela de processos 
(em baixo) correspondente às fases do tratamento de um sinal. (a) Estado quando o processo 
é retirado da execução. (b) Estado quando a rotina de tratamento começa a execução. (c) Es- 
tado enquanto sigreturn está executando. (d) Estado após sigreturn concluir a execução. (ip 
significa instruction pointer, ou seja, contador de programa) 


da função de biblioteca que ativa sigreturn em si, end de ret1, e outro endereço de retorno, end 
de ret2, que é o endereço onde a execução do programa interrompido será retomada. Confor- 
me veremos, entretanto, este último endereço não é usado durante a execução normal. 

Embora a rotina de tratamento seja escrita como uma função normal pelo programador, 
ela não é chamada através de uma invocação normal. O campo do instruction pointer (conta- 
dor de programa) no quadro de pilha da tabela de processos é alterado para fazer a rotina de 
tratamento de sinal começar a executar quando restart colocar o processo sinalizado nova- 
mente em execução. A Figura 4-43(b) mostra a situação após essa preparação ter terminado e 
quando a rotina de tratamento de sinal é executada. Lembre-se de que a rotina de tratamento 
de sinal é uma função normal; portanto, quando ela termina, end de retl é retirado da pilha e 
sigreturn executa. 

A parte (c) mostra a situação enquanto sigreturn está em execução. Agora, o restante da 
estrutura sigframe são variáveis locais de sigreturn. Parte da ação de sigreturn é ajustar seu 
próprio ponteiro de pilha (stack pointer) de modo que, se fosse terminar como uma função 
normal, usaria end de ret? como endereço de retorno. Entretanto, sigreturn não termina dessa 
maneira realmente. Ela termina como outras chamadas de sistema, permitindo que o esca- 
lonador decida qual processo será executado. Quando o processo sinalizado for executado 
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ele reiniciará nesse endereço, pois o endereço também está no quadro de pilha original do 
processo. O motivo desse endereço estar na pilha é que um usuário pode querer rastrear a 
execução de um programa usando um depurador, e isso engana o depurador, fazendo-o ter 
uma interpretação razoável da pilha enquanto uma rotina de tratamento de sinal está sendo 
rastreada. Em cada fase, a pilha é parecida com a de um processo normal, com variáveis lo- 
cais no topo de um endereço de retorno. 

O trabalho real de sigreturn é restaurar as coisas no estado em que estavam antes que 
o sinal fosse recebido, além de fazer a limpeza. Sobretudo, o quadro de pilha na tabela de 
processos é restaurado ao seu estado original, usando a cópia que foi salva na pilha do pro- 
cesso sinalizado. Quando sigreturn terminar, a situação será a da Figura 4-43(d), que mostra 
o processo esperando para entrar novamente em execução, no mesmo estado em que estava 
quando foi interrompido. 

Para a maioria dos sinais, a ação padrão é eliminar o processo sinalizado. O gerenciador 
de processos trata disso para todo sinal que não seja ignorado por padrão e que o processo 
de destino não tenha sido preparado para manipular, bloquear ou ignorar. Se o processo pai 
estiver esperando pelo filho, o processo filho será eliminado e removido da tabela de proces- 
sos. Se o processo pai não estiver esperando, ele se tornará um zumbi. Para certos sinais (por 
exemplo, SIGQUIT), o PM também gera um core dump do processo no diretório corrente. 

Facilmente pode acontecer de um sinal ser enviado para um processo que está corren- 
temente bloqueado, esperando por uma operação read em um terminal para o qual nenhuma 
entrada está disponível. Se o processo não tiver especificado que o sinal deve ser capturado, 
ele é simplesmente eliminado da maneira normal. Entretanto, se o sinal for capturado, surge 
a questão do que fazer após a interrupção do sinal ter sido processada. O processo deve voltar 
a esperar ou deve continuar com a próxima instrução”? Decisões, decisões. 

O que o MINIX 3 faz é o seguinte: a chamada de sistema termina de modo a retornar o 
código de erro EINTR, para que o processo possa ver que a chamada foi interrompida por um 
sinal. Determinar que um processo sinalizado foi bloqueado em uma chamada de sistema não 
é totalmente simples. O PM precisa pedir para que o sistema de arquivos verifique isso. 

Esse comportamento é sugerido (mas não exigido) pelo POSIX, que também permite 
que uma operação read retorne o número de bytes lidos até o momento da recepção do sinal. 
Retornar EINTR torna possível configurar um alarme e capturar sigalrm. Essa é uma maneira 
fácil de implementar um tempo limite, por exemplo, para terminar login e desligar uma linha 
de modem, caso um usuário não responda dentro de certo período de tempo. 


Temporizadores em espaço de usuário 


Gerar um alarme para despertar um processo após um período de tempo predefinido é um dos 
usos mais comuns dos sinais. Em um sistema operacional convencional, os alarmes seriam 
gerenciados inteiramente pelo núcleo ou por um driver de relógio executando em espaço de 
núcleo. No MINIX 3, a responsabilidade sobre alarmes para processos de usuário é delega- 
da ao gerenciador de processos. A idéia é aliviar a carga do núcleo e simplificar o código 
executado em espaço de núcleo. Se é verdade que algum número b de erros são inevitáveis 
por algum número [ de linhas de código, é razoável esperar que um núcleo menor contenha 
menos erros. Mesmo que o número total de erros permaneça o mesmo, seus efeitos deverão 
ser menos sérios se eles ocorrerem em componentes do sistema operacional em espaço de 
usuário, em vez de ocorrerem no próprio núcleo. 

Podemos manipular alarmes sem depender de código em espaço de núcleo? No MINIX 
3, pelo menos, a resposta é não, claro que não. Os alarmes são gerenciados em primeiro lugar 
pela tarefa de relógio em espaço de núcleo, que mantém uma lista encadeada (ou fila) de 
temporizadores, conforme esquematizado na Figura 2-49. Em cada interrupção do relógio, o 
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tempo de expiração do temporizador que está no início da fila é comparado com o tempo cor- 
rente e, se ele tiver expirado, o laço principal da tarefa de relógio será ativado. Então, a tarefa 
de relógio fará uma notificação ser enviada para o processo que solicitou o alarme. 

A inovação no MINIX 3 é que os temporizadores em espaço de núcleo são mantidos 
apenas para processos de sistema. O gerenciador de processos mantém outra fila de tem- 
porizadores em nome dos processos de usuário que solicitaram alarmes. O gerenciador de 
processos solicita um alarme do relógio apenas para o temporizador que está no início de sua 
fila. Se uma nova requisição não for adicionada no início da fila, nenhuma requisição para 
o relógio será necessária no momento em que ela for adicionada. (É claro que, na verdade, 
uma requisição de alarme é feita por meio da tarefa de sistema, pois a tarefa de relógio não 
se comunica diretamente com nenhum outro processo.) Quando a expiração de um alarme 
for detectada após uma interrupção de relógio vem uma notificação para o gerenciador de 
processos. Então, o PM faz todo o trabalho de verificar sua própria fila de temporizadores, 
sinalizar os processos de usuário e, possivelmente, solicitar outro alarme, se ainda houver 
uma requisição de alarme ativa no início de sua lista. 

Até aqui, não parece que há muita economia de trabalho no nível do núcleo, mas exis- 
tem várias outras considerações. Primeiro, existe a possibilidade de que mais de um tempori- 
zador expirado possa ser encontrado em um tique de relógio específico. Pode parecer impro- 
vável que dois processos solicitem alarmes ao mesmo tempo. Entretanto, embora o relógio 
verifique as expirações de temporizador a cada interrupção de relógio, conforme vimos, às 
vezes as interrupções estão desativadas. Uma chamada para a BIOS do PC pode causar uma 
perda de interrupções suficiente para que seja feito um preparativo especial para capturá-las. 
Isso significa que o tempo mantido pela tarefa de relógio pode pular por múltiplos tiques, 
tornando possível que vários tempos limites precisem ser manipulados simultaneamente. Se 
eles forem manipulados pelo gerenciador de processos, o código em espaço dd núcleo não 
precisará percorrer sua própria lista encadeada, limpando-a e gerando várias notificações. 

Segundo, os alarmes podem ser cancelados. Um processo de usuário pode terminar an- 
tes que um temporizador configurado em seu nome expire. Ou então, um temporizador pode 
ter sido configurado como backup para evitar que um processo espere para sempre por um 
evento que poderia nunca ocorrer. Quando o evento ocorrer, o alarme poderá ser cancelado. 
Claramente, a carga sobre o código em espaço de núcleo será diminuída se o cancelamento de 
temporizadores for feito em uma fila mantida pelo gerenciador de processos e não no núcleo. 
A fila em espaço de núcleo só precisa de atenção quando o temporizador que está em seu iní- 
cio expira, ou quando o gerenciador de processos fizer uma alteração no início de sua fila. 

A implementação de temporizadores será mais fácil de entender se dermos uma rápida 
olhada agora nas funções usadas no tratamento de um alarme. Muitas funções no gerenciador 
de processos e no núcleo são complicadas e é difícil ver o quadro geral quando se examina os 
detalhes, uma função por vez. 

Quando o PM configura um alarme em nome de um processo de usuário, um tempori- 
zador é inicializado por set alarm. A estrutura do temporizador tem campos para o tempo de 
expiração, para o processo em nome do qual o alarme é configurado e um ponteiro para uma 
função a ser executada. Para alarmes, essa função é sempre cause sigalarm. Então, a tarefa 
de sistema é solicitada a configurar um alarme em espaço de núcleo. Quando esse tempori- 
zador expira, um processo cão de guarda, no núcleo, cause alarm, é executado e envia uma 
notificação para o gerenciador de processos. Várias funções e macros estão envolvidos nisso, 
mas finalmente essa notificação é recebida pela função get work do gerenciador de proces- 
sos e detectada como uma mensagem de tipo SYN ALARM no laço principal do PM, o qual 
chama sua função pm expire timers. Agora, várias outras funções no espaço do gerenciador 
de processos são usadas. Uma função de biblioteca, tmrs exptimers, faz a função de cão de 
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guarda cause sigalrm ser executada, a qual chama checksig, que chama sig proc. Em segui- 
da, sig proc decide se vai eliminar o processo ou enviar SIGALRM para ele. Finalmente, é 
claro que o envio do sinal exige pedir ajuda para a tarefa de sistema em espaço de núcleo, pois 
são manipulados dados na tabela de processos e no espaço de pilha do processo sinalizado, 
conforme foi descrito na Figura 4-43. 


Outras chamadas de sistema 


O gerenciador de processos também manipula algumas chamadas de sistema mais simples. 
Time e stime tratam com o relógio de tempo real. A chamada times obtém tempos de con- 
tabilização do processo. Eles são manipuladas aqui principalmente porque o PM é um lugar 
conveniente para colocá-los. (Vamos discutir outra chamada relacionada ao tempo, utime, 
quando estudarmos sistemas de arquivos, no Capítulo 5, pois ela armazena nos i-nodes as 
informações temporais de modificação de arquivo.) 

As funções de biblioteca getuid e geteuid ativam, ambas, a chamada de sistema getuid, 
a qual retorna os dois valores em sua mensagem de retorno. Analogamente, a chamada de 
sistema getgid também retorna valores real e efetivo para uso das funções getgid e getegid. 
getpid funciona da mesma maneira para retornar o ID do processo e o ID do processo pai, e 
setuid e setgid configuram, cada uma delas, os valores real e efetivo em uma única chamada. 
Existem duas chamadas de sistema adicionais nesse grupo, getpgrp e setsid. A primeira retor- 
na o ID de grupo do processo e a última o configura com o valor do PID corrente. Essas sete 
chamadas de sistema são as mais simples do MINIX 3. 

As chamadas de sistema ptrace e reboot também são manipuladas pelo PM. A primeira 
oferece suporte para a depuração de programas. A última afeta muitos aspectos do sistema. 
É apropriado colocá-la no PM, pois sua primeira ação é enviar sinais para eliminar todos os 
processos, exceto o init. Depois disso, ela chama o sistema de arquivos e a tarefa de sistema 
para concluir seu trabalho. 


IMPLEMENTAÇÃO DO GERENCIADOR 
DE PROCESSOS DO MINIX 3 


Munidos com uma visão geral do funcionamento do gerenciador de processos, vamos passar 
agora ao código propriamente dito. O PM é escrito inteiramente em C, é simples e contém um 
volume substancial de comentários no próprio código; portanto, nosso tratamento da maioria 
das partes não precisa ser longo nem complicado. Primeiro, veremos resumidamente os ar- 
quivos de cabeçalho, em seguida o programa principal e, finalmente, os arquivos dos vários 
grupos de chamada de sistema discutidos anteriormente. 


Os arquivos de cabeçalho e as estruturas de dados 


Vários arquivos de cabeçalho no diretório de código-fonte do PM têm os mesmos nomes dos 
arquivos no diretório do núcleo; esses nomes serão vistos novamente no sistema de arquivos. 
Esses arquivos têm funções semelhantes em seus próprios contextos. A estrutura paralela é 
projetada para tornar mais fácil entender a organização do sistema MINIX 3 inteiro. O PM tam- 
bém tem vários cabeçalhos com nomes exclusivos. Assim como acontece em outras partes do 
sistema, o armazenamento de variáveis globais é reservado quando a versão do PM de table.c é 
compilada. Nesta seção, veremos todos os arquivos de cabeçalho, assim como table.c. 

Assim como acontece com outras partes importantes do MINIX 3, o PM tem um ar- 
quivo de cabeçalho mestre, pm.h (linha 17000). Ele é incluído em cada compilação e, por 
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sua vez, inclui todos os arquivos de cabeçalho gerais do sistema a partir de /usr/include e de 
seus subdiretórios, necessários para cada módulo objeto. A maioria dos arquivos incluídos 
em kernel/kernel.h também é incluída aqui. O PM também precisa de algumas definições em 
include/fcntl.h e include/unistd.h. As versões do próprio PM de const.h, type.h, proto.h e glo.h 
também são incluídas. Vimos uma estrutura semelhante no núcleo. 

Const.h (linha 17100) define algumas constantes usadas pelo PM. 

Type.h não é utilizado atualmente e existe em forma de esqueleto apenas para que os 
arquivos do PM tenham a mesma organização das outras partes do MINIX 3. Proto.h (linha 
17300) reúne em um só lugar os protótipos de função necessários em todo o PM. Definições 
“vazias” de algumas funções necessárias quando o swapping é compilado no MINIX 3 são 
encontradas nas linhas 17313 e 17314. Colocar essas macros aqui simplifica a compilação de 
uma versão sem swapping; caso contrário, muitos outros arquivos de código-fonte teriam de 
ser modificados para remover as chamadas para essas funções. 

As variáveis globais do PM são declaradas em glo.h (linha 17500). O mesmo truque 
usado no núcleo, com EXTERN, é usado aqui; a saber, EXTERN normalmente é uma macro 
que se expande em extern, exceto no arquivo table.c. Lá, ela se torna a string nula para que 
possa ser reservado armazenamento para as variáveis declaradas como EXTERN. 

A primeira dessas variáveis, mp, é um ponteiro para uma estrutura mproc, a parte do 
PM da tabela de processos do processo cuja chamada de sistema está sendo processada. A 
segunda variável, procs in use, monitora quantas entradas de processo estão correntemente 
em uso, facilitando verificar se uma chamada de fork é viável. 

O buffer de mensagens m in serve para mensagens de requisição. Who é o índice do 
processo corrente; ele é relacionado a mp por 


mp = &mproc[who]; 


Quando chega uma mensagem, o número da chamada de sistema é extraído e colocado em 
call nr. 

O MINIX 3 escreve a imagem de um processo em um arquivo core quando um processo 
termina de forma anormal. Core name define o nome que esse arquivo terá, core sset é um 
mapa de bits que define quais sinais devem produzir core dumps e ign sset é um mapa de bits 
informando quais sinais devem ser ignorados. Note que core name é definida como extern e 
não como EXTERN. O array call vec também é declarado como extern. O motivo de fazer 
essas duas declarações dessa maneira será explicado quando discutirmos table.c. 

A parte do PM da tabela de processos está no próximo arquivo, mproc.h (linha 17600). A 
maioria dos campos está adequadamente descrita por seus comentários. Vários campos tratam 
com manipulação de sinal. Mp ignore, mp catch, mp sig2mess, mp sigmask, mp sigmask2 e 
mp sigpending são mapas de bits, nos quais cada bit representa um dos sinais que podem ser 
enviados para um processo. O tipo sigset t é um inteiro de 32 bits, de modo que o MINIX 
3 poderia suportar até 32 sinais. Atualmente, são definidos 22 sinais, embora alguns não 
sejam suportados, conforme permitido pelo padrão POSIX. O sinal 1 é o bit menos signifi- 
cativo (mais à direita). Em qualquer caso, o POSIX exige funções padrão para adicionar ou 
excluir membros dos conjuntos de sinais representados por esses mapas de bits, de modo 
que todas as manipulações necessárias podem ser feitas sem que o programador saiba des- 
ses detalhes. O array mp. sigact é importante para tratamento de sinais. É fornecido um 
elemento para cada tipo de sinal e cada elemento é uma estrutura sigaction (definida no 
arquivo include/signal.h). Cada estrutura sigaction consiste em três campos: 


1. O campo sa handler define se o sinal deve ser manipulado da maneira padrão, 
ignorado ou manipulado por uma rotina de tratamento especial. 
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2. O campo sa mask é uma variável sigset t que define quais sinais devem ser blo- 
queados quando o sinal está sendo manipulado por uma rotina de tratamento per- 
sonalizada. 


3. O campo sa flags é um conjunto de flags que se aplicam ao sinal. 


Essa organização aumenta muito a flexibilidade no tratamento de sinais. 

O campo mp flags é usado para conter um conjunto diversificado de bits, conforme 
indicado no final do arquivo. Esse campo é um inteiro sem sinal, de 16 bits em CPUs de baixo 
poder de computação ou de 32 bits em um 386 e superiores. 

O campo seguinte na tabela de processos é mp procargs. Quando um novo processo 
é iniciado, é construída uma pilha como a que aparece na Figura 4-38 e um ponteiro para o 
início do array argv do novo processo é armazenado aqui. Isso é usado pelo comando ps. Por 
exemplo, para o caso da Figura 4-38, o valor 8164 seria armazenado aqui, tornando possível 
que ps exiba a linha de comando, 


Is -l f.c g.c 


se for executado enquanto o comando ls estiver ativo. 

O campo mp swapq não é usado no MINIX 3, conforme descrito aqui. Ele é usado 
quando o swapping está ativado e aponta para uma fila de processos que estão esperando por 
swap. O campo mp reply é onde é construída uma mensagem de resposta. Nas versões an- 
teriores do MINIX era fornecido um campo assim, definido em glo.h e, portanto, compilado 
quando table.c era compilado. No MINIX 3, é fornecido uma área para cada processo para 
construir uma mensagem de resposta. Fornecer um lugar para uma resposta em cada entrada 
da tabela de processos permite que o PM trate de outra mensagem recebida, caso uma respos- 
ta não possa ser enviada imediatamente após o término da construção da resposta. O PM não 
pode tratar de duas requisições simultaneamente, mas pode adiar respostas, se necessário, e 
pôr em dia esse tratamento tentando enviar todas as respostas pendentes sempre que concluir 
uma requisição. 

Os dois últimos itens na tabela de processos podem ser considerados supérfluos. Mp nice 
fornece um lugar, em cada processo, para ser atribuído um “valor de cortesia” (nice), para que 
os usuários possam diminuir a prioridade de seus processos, por exemplo, para permitir que um 
processo em execução passe a vez para outro mais importante. Entretanto, o MINIX 3 usa esse 
campo internamente para fornecer diferentes prioridades aos processos de sistema (servidores e 
drivers), dependendo de suas necessidades. O campo mp name é conveniente para depuração, 
ajudando o programador a identificar uma entrada na tabela de processos em um dump de me- 
mória. Está disponível uma chamada de sistema para procurar um nome de processo na tabela 
de processos e retornar o ID de um processo. 

Finalmente, note que a parte do gerenciador de processos da tabela de processos é de- 
clarada como um array de tamanho NR PROCS (linha 17655). Lembre-se de que a parte 
do núcleo da tabela de processos foi declarada como um array de tamanho NR TASKS + 
NR PROCS em kernel/proc.h (linha 5593). Conforme mencionado anteriormente, os pro- 
cessos compilados no núcleo não são conhecidos dos componentes do espaço de usuário do 
sistema operacional, como o gerenciador de processos. Eles não são realmente processos de 
primeira classe. 

O próximo arquivo é param.h (linha 177700), que contém macros para muitos parâme- 
tros de chamadas de sistema contidos na mensagem de requisição. Ele também contém 12 
macros para campos na mensagem de resposta e três macros usadas apenas em mensagens 
para o sistema de arquivos. Por exemplo, se a instrução 


k = m_in.pid; 
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aparece em qualquer arquivo no qual param.h é incluído, o pré-processador C a converte em 
k=miinmi il; 


antes de enviá-la para o compilador correto (linha 17707). 

Antes de continuarmos com o código executável, vamos ver table.c (linha 17800). A 
compilação desse arquivo reserva espaço de armazenamento para as diversas variáveis EX- 
TERN e estruturas que vimos em glo.h e mproc.h. A instrução 


tdefine TABLE 


faz EXTERN se tornar a string nula. Esse é o mesmo mecanismo que vimos no código do 
núcleo. Conforme mencionamos anteriormente, core name foi declarada como extern e não 
como EXTERN em glo.h. Agora, podemos ver porque. Aqui, core name é declarada com 
uma string de inicialização. A inicialização não é possível dentro de uma definição extern. 

O outro recurso importante de table.c é o array call vec (linha 17815). Ele também é 
um array inicializado e, assim, não poderia ser declarado como EXTERN em glo.h. Quando 
chega uma mensagem de requisição, o número da chamada de sistema é extraído e usado 
como índice em call vec para localizar a função que executa essa chamada de sistema. Todos 
os números de chamada de sistema que não são chamadas válidas ativam no sys, que apenas 
retorna um código de erro. Note que, embora a macro PROTOTYPE seja usada na definição 
de call vec, essa não é uma declaração de um protótipo, mas a definição de um array ini- 
cializado. Entretanto, trata-se de um array de funções e o uso de PROTOTYPE é a maneira 
mais fácil de fazer isso, que é compatível com a linguagem C clássica (Kernighan & Ritchie) 
e com o Standard C. 

Uma última nota sobre os arquivos de cabeçalho: como o MINIX 3 ainda está sendo 
ativamente desenvolvido, ainda existem algumas rebarbas. Uma delas é que alguns arquivos 
de código-fonte em pm/ incluem arquivos de cabeçalho do diretório do núcleo. Se você não 
estiver ciente disso, poderá ser difícil encontrar algumas definições importantes. Com cer- 
teza, as definições usadas por mais de um componente importante do MINIX 3 deverão ser 
consolidadas em arquivos de cabeçalho no diretório include/. 


O programa principal 
O gerenciador de processos é compilado e ligado independentemente do núcleo e do sistema 
de arquivos. Consegiientemente, ele tem seu próprio programa principal, o qual é executado 
logo depois que o núcleo tiver terminado de inicializar. O ponto de entrada está na linha 
18041 em main.c. Após fazer sua própria inicialização, chamando pm init, o PM entra em 
seu laço na linha 18051. Nesse laço, ele chama get work para esperar o recebimento de uma 
mensagem de requisição. Então, ele chama uma de suas funções do xxx, por meio da tabela 
call vec, para executar essa requisição. Finalmente, se necessário, ele envia uma resposta. 
Essa construção já deve ser conhecida agora: é a mesma usada pelas tarefas de E/S. 

A descrição anterior está ligeiramente simplificada. Conforme mencionado no Capítulo 
2, mensagens de notificação podem ser enviadas para qualquer processo. Elas são identi- 
ficadas por valores especiais no campo call nr. Nas linhas 18055 a 18062, é feito um teste 
para os dois tipos de mensagens de notificação que o PM pode receber e uma ação especial é 
executada nesses casos. Além disso, é feito um teste para uma variável call nr válida na linha 
18064, antes de ser feita uma tentativa de executar uma requisição (na linha 18067). Embora 
uma requisição inválida seja improvável, não custa muito fazer esse teste se comparado com 
as consegiiências desastrosas de uma requisição inválida. 
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Outro ponto digno de nota é a chamada para swap in, na linha 18073. Conforme men- 
cionamos no contexto de proto.h, no MINIX 3, da forma como ele está configurado para a 
descrição neste texto, essa é uma chamada vazia. Mas se o sistema for compilado com o con- 
junto de código-fonte completo, com o swapping ativado, é aí que será feito o teste para ver 
se um processo poderia ser trazido do disco. 

Finalmente, embora o comentário na linha 18070 indique que é aqui que uma resposta 
de retorno é enviada, essa também é uma simplificação. A chamada para setreply constrói 
uma resposta na área que mencionamos anteriormente, na entrada da tabela de processos do 
processo corrente. Então, nas linhas 18078 a 18091 do laço, todas as entradas da tabela de 
processos são verificadas e todas as respostas pendentes que puderem ser enviadas são envia- 
das, pulando as que não puderem ser nesse momento. 

As funções get work (linha 18099) e setreply (linha 18116) manipulam a recepção e o 
envio reais, respectivamente. A função get work realiza um pequeno truque para fazer com 
que uma mensagem do núcleo pareça ter sido do próprio PM, pois o núcleo não tem uma 
entrada para si na tabela de processos. A função setreply não envia a resposta realmente; ela a 
configura para ser enviada posteriormente, conforme mencionamos antes. 


Inicialização do gerenciador de processos 


A função mais longa em main.c é pm. init, que inicializa o PM. Depois que o sistema come- 
çou a executar, ela não é mais usada. Mesmo que os drivers e servidores sejam compilados 
separadamente e executados como processos separados, alguns deles são carregados como 
parte da imagem de inicialização (boot image) pelo monitor de inicialização. É difícil ver 
como qualquer sistema operacional poderia ser iniciado sem um PM e um sistema de arqui- 
vos; portanto, esses componentes provavelmente sempre precisarão ser carregados na memó- 
ria pelo monitor de inicialização. Alguns drivers de dispositivo também são carregados como 
parte da imagem. Embora seja um objetivo do MINIX 3 tornar o máximo possível de drivers 
carregáveis independentemente, é difícil, por exemplo, como fazer para evitar o carregamento 
de um driver de disco no início das atividades. 

A maior parte do trabalho de pm init é inicializar as tabelas do PM para que todos 
os processos carregados possam ser executados. Conforme observado anteriormente, o PM 
mantém duas estruturas de dados importantes, a tabela de lacunas (ou tabela de memória 
livre) e uma parte da tabela de processos. Consideraremos primeiro a tabela de lacunas. A 
inicialização da memória é complicada. Será mais fácil entender a descrição a seguir se mos- 
trarmos primeiro como a memória é organizada quando o PM é ativado. O MINIX 3 fornece 
todas as informações que precisamos para isso. 

Antes que a imagem de inicialização em si do MINIX 3 seja carregada na memória, o 
monitor de inicialização determina o layout da memória disponível. No menu de inicializa- 
ção, você pode pressionar a tecla ESC para ver os parâmetros que estão sendo usados. Uma 
linha na tela mostra os blocos de memória não utilizados e é semelhante à seguinte: 


memory = 800:923€0,100000:3df0000 


(Depois que o MINIX 3 inicia, você também pode ver essas informações usando o comando 
sysenv ou a tecla F5. Os números exatos que você vai ver podem ser diferentes, é claro.) 

Isso mostra dois blocos de memória livres. Além disso, existem dois blocos de memória 
utilizados. A memória abaixo de 0x800 é usada para dados da BIOS, pelo registro de iniciali- 
zação mestre (master boot record) e pelo bloco de inicialização (bootblock). Na verdade, não 
importa como a memória é usada; ela não está disponível quando o monitor de inicialização 
começa. A memória livre a partir de 0x800 é a “memória de base” dos computadores compatí- 
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veis com IBM. Nesse exemplo, a partir do endereço 0x800 (2048) existem 0x923€e0 (599008) 
bytes disponíveis. Acima disso está a “área de memória superior”, de 640 KB a 1 MB, que 
está fora dos limites para programas normais — ela é reservada para ROM e RAM dedicada 
em adaptadores de E/S. Finalmente, no endereço 0x 100000 (1 MB) existem 0x3df0000 bytes 
livres. Esse intervalo é comumente referenciado como “memória estendida”. Esse exemplo 
indica que o computador tem um total de 64 MB de memória RAM instalados. 

Se você está acompanhando esses números, terá notado que a quantidade de memória 
de base livre é menor do que os 638 KB que poderia esperar. O monitor de inicialização do 
MINIX 3 é carregado o mais alto possível nesse intervalo e exige cerca de 52 KB. Neste 
exemplo, cerca de 584 KB estão realmente livres. Este é um bom lugar para observar que 
o uso da memória poderia ser mais complicado do que neste exemplo. Por exemplo, um 
método de execução do MINIX, ainda não portado para o MINIX 3 quando este livro estava 
sendo produzido, utiliza um arquivo do MS-DOS para simular um disco do MINIX. A técnica 
exige carregar alguns componentes do MS-DOS antes de iniciar o monitor de inicialização 
do MINIX 3. Se eles não forem carregados em posições adjacentes às regiões de memória 
que já estão em uso, mais de duas regiões de memória livre serão relatadas pelo monitor de 
inicialização. 

Quando o monitor de inicialização carrega a imagem de inicialização na memória, in- 
formações sobre os componentes da imagem são exibidas na tela do console. A Figura 4-44 
mostra parte dessa tela. Neste exemplo (típico, mas possivelmente não idêntico ao que você 
verá, pois este foi extraído de uma versão de pré-lançamento do MINIX 3), o monitor de ini- 
cialização carregou o núcleo na memória livre no endereço 0x800. O PM, o sistema de arqui- 
vos, o servidor de reencarnação e outros componentes não mostrados na figura, são instalados 
no bloco de memória livre que começa em 1 MB. Essa foi uma escolha de projeto arbitrária; 
permanece memória suficiente abaixo do limite de 588 KB para alguns desses componentes. 
Entretanto, quando o MINIX 3 é compilado com uma cache de bloco grande, como acontece 
neste exemplo, o sistema de arquivos não cabe no espaço imediatamente acima do núcleo. 
Foi mais fácil, mas de modo algum fundamental, apenas carregar tudo na região superior da 
memória. Nada é perdido por isso, o gerenciador de memória pode usar a lacuna na memó- 
ria abaixo de 588 KB quando o sistema estiver executando e os processos de usuário forem 
iniciados. 


cs ds text data bss stack 
0000800 0005800 19552 3140 30076 O — núcleo 
0100000 0104c00 19456 2356 48612 1024 pm 
0111800 011c400 43216 5912 6224364 2048 fs 
070000 0701400 4352 616 4696 131072 rs 


Figura 4-44 Tela do monitor de inicialização com a utilização de memória dos primeiros 
componentes da imagem de inicialização. 


A inicialização do PM começa com um laço pela tabela de processos para desativar o 
temporizador de cada entrada, para que nenhum alarme espúrio possa ocorrer. Então, são ini- 
cializadas as variáveis globais que definem os conjuntos padrão de sinais que serão ignorados 
ou que causarão core dumps. Em seguida, são processadas as informações que vimos sobre 
o uso da memória. Na linha 18182, a tarefa de sistema recupera a string memory do monitor 
de inicialização, que vimos anteriormente. Em nosso exemplo, existem dois pares base:ta- 
manho mostrando blocos de memória livres. A chamada para get mem. chunks (linha 18184) 
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converte os dados da string em ASCII para binário e insere os valores de base e tamanho no 
array mem. chunks (linha 18192), cujos elementos são definidos como 


struct memory (phys clicks base; phys clicks size;); 


Mem. chunks ainda não está na lista de lacunas; ele é apenas um pequeno array no qual essas 
informações são reunidas, antes da inicialização da lista de lacunas. 

Após consultar o núcleo e converter informações sobre o uso de memória do núcleo em 
unidades de clicks, patch mem chunks é chamada para subtrair a utilização do núcleo do ar- 
ray mem chunks. Agora, a memória que estava sendo usada antes da inicialização do MINIX 
3 é contabilizada, assim como a memória usada pelo núcleo. Mem chunks não está completa, 
mas a memória usada por processos normais na imagem de inicialização será contabilizada 
dentro do laço, nas linhas 18201 a 18239, que inicializa entradas da tabela de processos. 

Informações sobre atributos de todos os processos que fazem parte da imagem de ini- 
cialização estão na tabela image, que foi declarada em kernel/table.c (linhas 6095 a 6109). 
Antes de entrar no laço principal, a chamada de núcleo sys getimage, na linha 18197, for- 
nece ao gerenciador de processos uma cópia da tabela image. (Rigorosamente falando, essa 
não é exatamente uma chamada de núcleo; trata-se de uma das mais de doze macros definidas 
em include/minix/syslib.h que fornecem interfaces fáceis de usar para a chamada de núcleo 
sys getinfo.) Os processos do núcleo não são conhecidos no espaço de usuário e as partes do 
PM (e do FS — file system) da tabela de processos não precisam da inicialização de processos 
do núcleo. Na verdade, não é reservado espaço para entradas de processo do núcleo. Cada 
uma delas tem um número de processo negativo (índice na tabela de processos) e são ignora- 
das pelo teste feito na linha 18202. Além disso, não é necessário chamar patch mem chunks 
para processos do núcleo; a consideração feita sobre o uso de memória do núcleo também 
vale para as tarefas compiladas no núcleo. 

Processos de sistema e processos de usuário precisam ser adicionados na tabela de 
processos, embora recebam tratamentos ligeiramente diferentes (linhas 18210 a 18219). O 
único processo de usuário carregado na imagem de inicialização é init, portanto, é feito um 
teste para INIT PROC NR (linha 18210). Todos os outros processos na imagem de iniciali- 
zação são processos de sistema. Os processos de sistema são especiais — eles não podem so- 
frer swap, cada um tem uma entrada dedicada na tabela priv no núcleo e possuem privilégios 
especiais, conforme indicado pelos seus flags. Para cada processo, os padrões corretos são 
configurados para processamento de sinal (com algumas diferenças entre os padrões para 
processos de sistema e init). Então, o mapa de memória de cada processo é obtido do nú- 
cleo, usando get mem map que, em última análise, ativa a chamada de núcleo sys getinfo, 
e patch mem. chunks é chamada para ajustar o array mem chunks (linhas 18225 a 18230) 
dessa maneira. 

Finalmente, uma mensagem é enviada para o sistema de arquivos, para que uma entrada 
para cada processo possa ser inicializada na parte do FS da tabela de processos (linhas 18233 
a 18236). A mensagem contém apenas o número do processo e o PID; isso é suficiente para 
inicializar a entrada da tabela de processos do FS, pois todos os processos na imagem de ini- 
cialização do sistema pertencem ao superusuário e podem receber os mesmos valores padrão. 
Cada mensagem é enviada com uma operação send; portanto, nenhuma resposta é esperada. 
Após o envio da mensagem, o nome do processo é exibido no console (linha 18237): 


Building process table: pm fs rs tty memory log driver init 


Nessa tela, driver é um substituto do driver de disco padrão; vários drivers de disco 
podem ser compilados na imagem de inicialização, sendo um deles selecionado como padrão 
por uma instrução label= nos parâmetros de inicialização. 
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A entrada do próprio PM na tabela de processos é um caso especial. Depois que o laço 
principal está terminado, o PM faz algumas alterações em sua própria entrada e então envia 
uma mensagem final para o sistema de arquivos com o valor simbólico NONE como número 
de processo. Essa mensagem é enviada com uma chamada sendrec e o gerenciador de pro- 
cessos é bloqueado, esperando uma resposta. Enquanto o PM executa o laço do código de 
inicialização, o sistema de arquivos faz um laço receive (nas linhas 24189 a 24202, caso você 
queira dar uma olhada no código a ser descrito no próximo capítulo). Receber a mensagem 
com o número de processo NONE informa ao FS que todos os processos de sistema foram 
inicializados, de modo que ele pode sair de seu laço e enviar (com send) uma mensagem de 
sincronização para desbloquear o PM. 

Agora, o FS está livre para continuar sua própria inicialização e, aqui no PM, a inicia- 
lização também está quase concluída. Na linha 18253, mem. init é chamada. Essa função re- 
cebe as informações que foram coletadas no array mem. chunks e inicializa a lista encadeada 
de regiões livres de memória e as variáveis relacionadas que serão usadas para gerenciamento 
de memória quando o sistema estiver sendo executado. O gerenciamento normal da memória 
começa após a impressão de uma mensagem no console, listando a memória total, a memória 
em uso pelo MINIX 3 e a memória disponível: 


Physical memory: total 63996 KB, system 12834 KB, free 51162 KB. 


A próxima função é get nice value (linha 18263). Ela é chamada para determinar 
o “nível de cortesia (nice)” de cada processo na imagem de inicialização. A tabela image 
fornece um valor de queue para cada processo da imagem de inicialização, definindo qual 
fila de prioridade será usada para o escalonamento do processo. Isso varia de O (para pro- 
cessos de alta prioridade, como CLOCK) até 15 (para IDLE). Mas o significado tradicional 
de “nível de cortesia” nos sistemas UNIX é um valor que pode ser positivo ou negativo. 
Assim, get nice value gradua os valores de prioridade do núcleo em uma escala centrali- 
zada em zero para processos de usuário. Isso é feito usando-se as constantes PRIO MIN e 
PRIO MAX definidas como macros em include/sys/resource.h (não listado), com valores 
de —20 e +20. Elas são graduadas entre MIN USER Q e MAX USER OQ, definidos em 
kernel/proc.h; portanto, se for tomada a decisão de fornecer menos ou mais filas para o 
escalonamento, o comando nice ainda funcionará. Init, o processo-raiz na árvore de pro- 
cessos de usuário, é posto na fila de prioridade 7 e recebe um valor nice igual a 0, que é 
herdado por um filho após uma operação fork. 

As duas últimas funções contidas em main.c já foram mencionadas de passagem. 
Get mem chunks (linha 18280) é chamada apenas uma vez. Ela recebe as informações de 
memória retornadas pelo monitor de inicialização como uma string em ASCII de pares he- 
xadecimais base:tamanho, converte as informações em unidades de clicks e as armazena 
no array mem. chunks. Patch mem chunks (linha 18333) continua a construção da lista de 
memória livre e é chamada várias vezes, uma para o próprio núcleo, uma para init e uma para 
cada um dos processos de sistema inicializados durante o laço principal de pm. init. Ela cor- 
rige as informações brutas do monitor de inicialização. Sua tarefa é mais fácil porque recebe 
seus dados em unidades de click. Para cada processo, pm. init recebe a base e o tamanho das 
alocações de texto e dados desse processo. Para cada processo, a base do último elemento 
no array de blocos livres é aumentada pela soma dos tamanhos dos segmentos de texto e 
de dados. Então, o tamanho desse bloco é diminuído pela mesma quantidade para marcar a 
memória desse processo como em uso. 
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4.8.3 Implementação de FORK, EXIT e WAIT 


As chamadas de sistema fork, exit e wait são implementadas pelas funções do fork, do pm. 
exite do waitpid no arquivo forkexit.c. A função do fork (linha 18430) segue as etapas mos- 
tradas na Figura 4-36. Note que a segunda chamada para procs in use (linha 18445) reserva 
as últimas entradas da tabela de processos para o superusuário. No cálculo da quantidade de 
memória necessária para o filho, é incluída a lacuna entre os segmentos de dados e de pilha, 
mas o segmento de texto, não. O texto do pai é compartilhado ou, se o processo tiver espaços 
de I e D comum, seu segmento de texto terá tamanho igual a zero. Após efetuar o cálculo, é 
feita uma chamada para alloc mem para obter a memória. Se isso for bem-sucedido, os en- 
dereços de base do filho e do pai serão convertidos de clicks para bytes absolutos e sys copy 
será chamada para enviar uma mensagem para a tarefa de sistema, para realizar a cópia. 

Agora é encontrada uma entrada na tabela de processos. O teste anterior envolvendo 
procs in use garante a existência de uma. Após a entrada ser encontrada, ela é preenchida, 
primeiro copiando a entrada do pai e depois atualizando os campos mp. parent, mp flags, 
mp child utime, mp child stime, mp seg,mp exitstatus emp sigstatus. Alguns desses cam- 
pos precisam de tratamento especial. Apenas certos bits no campo mp flags são herdados. O 
campo mp seg é um array contendo elementos dos segmentos de texto, de dados e de pilha, 
e a parte referente ao texto fica apontando para o segmento de texto do pai, caso os flags indi- 
quem que esse é um programa de I e D separados que pode compartilhar texto. 

O próximo passo é atribuir um PID ao filho. A chamada para get free pid faz o que seu 
nome indica (obter pid livre). Isso não é tão simples como se pensa e descreveremos a função 
mais adiante. 

Sys fork e tell fs informam ao núcleo e ao sistema de arquivos, respectivamente, que 
um novo processo foi criado, para que eles possam atualizar suas tabelas de processos. (Todas 
as funções que começam com sys. são rotinas de biblioteca que enviam uma mensagem para 
a tarefa de sistema no núcleo para solicitar um dos serviços da Figura 2-45.) A criação e a 
destruição de processos são sempre iniciadas pelo PM e depois propagadas para o núcleo e 
para o sistema de arquivos, quando concluída. 

A mensagem de resposta para o filho é enviada explicitamente no final de do fork. A 
resposta para o pai, contendo o PID do filho, é enviada pelo laço em main, como a resposta 
normal a uma requisição. 

A próxima chamada de sistema manipulada pelo PM é exit. A função do pm. exit (linha 
18509) aceita a chamada, mas a maior parte do trabalho é feita pela chamada para pm exit, 
algumas linhas depois. O motivo dessa divisão de trabalho é que pm. exit também é chamada 
para cuidar dos processos terminados por um sinal. O trabalho é o mesmo, mas os parâmetros 
são diferentes; portanto, é conveniente dividir as coisas dessa maneira. 

A primeira atividade de pm. exit é parar o temporizador, caso o processo tenha um em 
execução. Então, o tempo usado pelo filho é adicionado na contagem do pai. Em seguida, 
o núcleo e o sistema de arquivos são notificados de que o processo não é mais executável 
(linhas 18550 e 18551). A chamada de núcleo sys exit envia uma mensagem para a tarefa de 
sistema dizendo para que ela limpe a entrada utilizada por esse processo na tabela de proces- 
sos do núcleo. Em seguida, a memória é liberada. Uma chamada para find share determina se 
o segmento de texto está sendo compartilhado por outro processo e, se não estiver, o segmen- 
to de texto será liberado por uma chamada para free mem. Isso é seguido por outra chamada 
para a mesma função, para liberar os dados e a pilha. Não vale a pena o trabalho de decidir se 
toda a memória poderia ser liberada em uma única chamada para free mem. Se o pai estiver 
esperando, cleanup será chamada para liberar a entrada da tabela de processos. Se o pai não 
estiver esperando, o processo se tornará um zumbi, o que é indicado pelo bit ZOMBIE na 
palavra mp flags, e será enviado um sinal SIGCHILD ao pai. 
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4.8.4 


Seja o processo completamente eliminado ou transformado em um zumbi, a última ação de 
pm. exit é varrer a tabela de processos procurando os filhos do processo que acabou de terminar 
(linhas 18582 a 18589). Se forem encontrados, eles serão deserdados e se tornarão filhos de init. 
Se init estiver esperando, e um filho estiver pendente, cleanup será chamada para esse filho. Isso 
trata de situações como aquela que aparece na Figura 4-45(a). Nessa figura, vemos que o pro- 
cesso 12 está para terminar e que seu pai, 7, está esperando por ele. Cleanup será chamada para 
se desfazer de 12, de modo que 52 e 53 se transformam em filhos de init, como se vê na Figura 
4-45(b). Agora temos uma situação em que 53, que quando terminar, será filho de um processo 
que está executando uma operação wait. Conseqiientemente, ele também pode ser eliminado. 


Gye CRY 


(6) QG 
Esperando (6) E) (8) (52) (53) 


= Terminando 


“~ Zumbi 
(a) (b) 


Figura 4-45 (a) A situação quando o processo 12 está para terminando. (b) A situação após 
ele ter terminado. 


Quando o processo pai executa uma operação wait ou waitpid, o controle vai para a fun- 
ção do_waitpid na linha 18598. Os parâmetros fornecidos pelas duas chamadas são diferentes 
e as ações esperadas também, mas a configuração feita nas linhas 18613 a 18615 prepara as 
variáveis internas de modo que do_waitpid possa executar as ações de uma chamada ou de 
outra. O laço nas linhas 18623 a 18642 percorre a tabela de processos inteira para ver se o 
processo tem filhos e, se tiver, verifica se existem zumbis que agora possam se eliminados. Se 
for encontrado um zumbi (linha 18630), ele será eliminado e do_waitpid retornará o código 
de retorno SUSPEND. Se for encontrado um filho que está sofrendo uma ação de geração de 
rastros (tracing), a mensagem de resposta que está sendo construída será modificada para 
indicar que o processo está parado e do_waitpid retornará. 

Se o processo que está executando a operação wait não tiver filhos, ele simplesmente 
receberá o retorno de um erro (linha 18653). Se ele tiver filhos, mas nenhum for zumbi ou es- 
tiver sendo rastreado, é feito um teste para verificar se o pai executou do_waitpid com a opção 
de não esperar pelo filho. Se ele estiver esperando (o caso normal), um bit é posicionado na 
linha 18648 para indicar esta situação e o pai será suspenso até que um filho termine. 

Quando um processo tiver terminado e seu pai estiver esperando por ele, qualquer que 
seja a ordem em que esses eventos ocorram, a função cleanup (linha 18660) será chamada 
para cumprir os ritos finais. Não resta muito a ser feito, nesse ponto. O pai é despertado a 
partir de sua chamada de wait ou waitpid e recebe o PID do filho terminado, assim como seu 
status de término e de sinal. O sistema de arquivos já liberou a memória do filho e o núcleo 
já suspendeu seu escalonamento e liberou a entrada do filho na tabela de processos. Nesse 
ponto, o processo filho deixou de existir para sempre. 


Implementação de EXEC 


O código de exec segue o esquema da Figura 4-40. Ele está contido na função do exec (li- 
nha 18747) em exec.c. Após fazer algumas verificações de validade, o PM busca o nome do 
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arquivo a ser executado a partir do espaço de usuário (linhas 18773 a 18776). Lembre-se de 
que as funções de biblioteca que implementam exec constroem uma pilha dentro da imagem 
de núcleo antiga, como vimos na Figura 4-38. Essa pilha é buscada em seguida, no espaço de 
memória do PM (linha 18782). 

Os próximos passos são escritos como um laço (linhas 18789 a 18801). Entretanto, 
para executáveis binários normais, ocorre apenas uma passagem pelo laço. Descreveremos 
esse caso primeiro. Na linha 18791, uma mensagem para o sistema de arquivos muda o dire- 
tório corrente para que o caminho até o arquivo seja interpretado relativamente ao diretório 
de trabalho do usuário e não do PM. Então, allowed é chamada — se o arquivo tiver permis- 
são de execução, ele é aberto. Se o teste falhar, um número negativo será retornado, em vez 
de um descritor de arquivo válido, e do exit terminará indicando falha. Se o arquivo estiver 
presente e for executável, o PM chamará read header e obterá os tamanhos de segmento. 
Para um binário normal, o código de retorno de read header causará uma saída do laço na 
linha 18800. 

Agora, veremos o que acontece se o executável for um script. O MINIX 3, assim como 
a maioria dos sistemas operacionais do tipo UNIX, suporta scripts executáveis. Read header 
testa os dois primeiros bytes do arquivo em busca da sequência mágica shebang (*!) e retorna 
um código especial se ela for encontrada, indicando a presença de um script. A primeira linha 
de um script marcado dessa maneira especifica o interpretador do script e, possivelmente, 
especifica também flags e opções do interpretador. Por exemplo, um script pode ser escrito 
com uma primeira linha como 


#! /bin/sh 
para mostrar que deve ser interpretado pelo Bourne shell ou como 
#! /usr/local/bin/perl -wT 


para ser interpretado com Perl, com flags ativados para alertar sobre possíveis problemas. 
Contudo, isso complica a tarefa de exec. Quando um script precisa ser executado, o arquivo 
que do exec deve carregar na memória não é o script em si. Em vez disso, deve ser carregado 
o binário do interpretador. Quando um script é identificado, patch stack é chamada na linha 
18801, no final do laço. 

O que patch stack faz pode ser ilustrado com um exemplo. Suponha que um script Perl 
seja chamado com alguns argumentos na linha de comando, como segue: 


perl. prog.pl file1 file2 


Se o script perl foi escrito com uma linha de shebang semelhante à que vimos anteriormente, 
patch stack cria uma pilha para executar o binário perl como se a linha de comando fosse: 


/usr/local/bin/perl -wT perl prog.pl file1 file2 


Se ela for bem-sucedida nisso, será retornada a primeira parte dessa linha, isto é, o caminho 
para o binário executável do interpretador. Então, o miolo do laço será executado mais uma 
vez, agora lendo o cabeçalho de arquivo e obtendo os tamanhos dos segmentos do arquivo 
a ser executado. Não é permitido que a primeira linha de um script aponte para outro script 
como seu interpretador. É por isso que foi usada a variável r. Ela só pode ser incrementada 
uma vez, possibilitando apenas uma chance de chamar patch stack. Se, na segunda vez que 
percorrer o laço, for encontrado o código que indica um script, o teste na linha 18800 ter- 
minará o laço. O código de um script, representado simbolicamente como ESCRIPT, é um 
número negativo (definido na linha 18741). Nesse caso, o teste na linha 18803 fará do exit 
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retornar com um código de erro informando se o problema é um arquivo que não pode ser 
executado ou uma linha de comando longa demais. 

Ainda resta algum trabalho a ser feito para completar a operação de exec. Find share 
verifica se o novo processo pode compartilhar texto com um processo que já está em execu- 
ção (linha 18809) e new mem aloca memória para a nova imagem e libera a memória antiga. 
Tanto a imagem na memória como a tabela de processos precisam estar prontas antes que 
o programa passado como argumento para exec possa ser executado. Nas linhas 18819 a 
18821, o i-node do arquivo executável, o sistema de arquivos e a hora de modificação são 
salvos na tabela de processos. Então, a pilha é corrigida, como na Figura 4-38(c), e copiada 
na nova imagem na memória. Em seguida, o texto (se já não estiver compartilhando texto) 
e os segmentos de dados são copiados do disco na imagem de memória, chamando rw seg 
(linhas 18834 a 18841). Se os bits setuid ou setgid estiverem ativos, o sistema de arquivos 
precisará ser notificado para colocar as informações de ID efetivo na parte do FS da entrada 
da tabela de processos (linhas 18845 a 18852). Na parte do PM da tabela de arquivos, é salvo 
um ponteiro para os argumentos do novo programa para que o comando ps possa mostrar a 
linha de comando, máscaras de bit de sinal são inicializadas, o FS é notificado para fechar os 
descritores de arquivo que devem ser fechados após uma operação exec e, finalmente, o nome 
do comando é salvo para exibição por ps ou durante a depuração (linhas 18856 a 18877). 
Normalmente, o último passo é informar o núcleo, mas se o rastreamento (tracing) estiver 
ativado, um sinal deverá ser enviado (linhas 18878 a 18881). 

Na descrição do funcionamento de do exec, mencionamos várias funções de suporte 
fornecidas em exec.c. Read header (linha 18889) não apenas lê o cabeçalho e retorna os ta- 
manhos de segmento, como também verifica se o arquivo é um executável válido do MINIX 3 
para o mesmo tipo de CPU para o qual o sistema operacional foi compilado. O valor constan- 
te 4 180366, na linha 18944, é determinado por uma sequência #ifdef ... fendifno momento 
da compilação. Os programas executáveis binários para o MINIX 3 de 32 bits em plataformas 
Intel devem ter essa constante em seus cabeçalhos para serem aceitos. Se o MINIX 3 fosse 
compilado para executar no modo de 16 bits, o valor aqui seria 4 18086. Se estiver curioso, 
você pode ver os valores definidos para outras CPUs em include/a.out.h. 

A função new mem (linha 18980) verifica se há memória disponível suficiente para a 
nova imagem de memória. Ela procura uma lacuna grande o bastante apenas para os dados e 
para a pilha, caso o texto esteja sendo compartilhado; caso contrário, ela procura uma única 
lacuna grande o bastante para o texto, para os dados e para a pilha combinados. Um possível 
aprimoramento aqui seria procurar duas lacunas separadas. Nas versões anteriores do MINIX, 
era exigido que os segmentos de texto e de dados/pilha fossem adjacentes, mas no MINIX 3 
isso não é necessário. Se for encontrada memória suficiente, a memória antiga será liberada e 
a nova memória será adquirida. Se não houver memória suficiente disponível, a chamada de 
exec falhará. Após a nova memória ser alocada, new mem atualiza o mapa de memória (em 
mp seg) e informa para o núcleo com a chamada de núcleo sys newmap. 

A última tarefa de new mem é zerar o segmento bss, a lacuna e o segmento de pilha. 
(O segmento bss é aquela parte do segmento de dados que contém todas as variáveis globais 
não inicializadas.) O trabalho é realizado pela tarefa de sistema, chamada por sys memset 
na linha 19064. Muitos compiladores geram código explícito para zerar o segmento bss, mas 
fazer isso aqui permite que o MINIX 3 funcione mesmo com compiladores que não geram. A 
lacuna entre os segmentos de dados e de pilha também é zerada para que, quando o segmento 
de dados for estendido por brk, a memória recentemente adquirida contenha zeros. Isso não 
é conveniente apenas para o programador, que pode contar com as variáveis novas tendo um 
valor inicial igual a zero, mas também é uma característica de segurança em um sistema ope- 
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racional multiusuário, onde um processo que estava usando essa memória anteriormente pode 
ter utilizado dados que não devem ser vistos por outros processos. 

A função seguinte, patch ptr (linha 19074), reposiciona ponteiros, como aqueles da Fi- 
gura 4-38(b), na forma da Figura 4-38(c). O funcionamento é simples: examinar a pilha para 
encontrar todos os ponteiros e adicionar o endereço de base a cada um deles. 

As duas funções seguintes trabalham juntas. Descrevemos seus objetivos anteriormen- 
te. Quando um script é executado com exec, o binário do interpretador do script é o executá- 
vel que deve ser executado. Insert arg (linha 19106) insere strings na cópia da pilha do PM. 
Isso é dirigido por patch stack (linha 19162), que encontra todas as strings na linha shebang 
do script e chama insert arg. Naturalmente, os ponteiros também têm de ser corrigidos. A 
tarefa de insert arg é simples, mas existem várias coisas que podem dar errado e devem ser 
testadas. Este é um bom lugar para mencionar que é particularmente importante verificar pro- 
blemas ao tratar com scripts. Afinal, os scripts podem ser escritos pelos usuários e todos os 
profissionais de computação reconhecem que os usuários fregiientemente são a principal cau- 
sa de problemas. Mas, falando sério, uma diferença importante entre um script e um binário 
compilado é que você geralmente pode confiar no fato de o compilador não gerar um arquivo 
binário quando encontra uma ampla variedade de erros sintáticos (e às vezes, semânticos) no 
código-fonte. Um script não é validado dessa maneira. 

A Figura 4-46 mostra como isso funcionaria para uma chamada para um shell script, 
s.sh, que opera em um arquivo f1. A linha de comando é como a seguinte: 


s.sh f1 
e a linha de shebang do script indica que ele deve ser interpretado pelo Bourne shell: 


#! /bin/sh 


Array de 
ambiente 


a 


HOME = /usr/ast HOME = /usr/ast 


Array de 
Array de argumentos 
argumentos efetivo 


f1 
s.sh 


(a) (b) 


s.sh 


Dt 
DO e hish 
Figura 4-46 (a). Arrays passados para execve e a pilha criada quando um script é executado. 


(b). Após o processamento por patch. stack, os arrays e a pilha ficam assim. O nome do script 
é passado para o programa que o interpreta. 
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4.8.5 


Na parte (a) da figura está a pilha copiada do espaço do processo que fez a chamada. A parte 
(b) mostra como isso é transformado por patch stack e insert arg. Esses dois diagramas 
correspondem à Figura 4-38(b). 

A função seguinte definida em in exec.c é rw seg (linha 19208). Ela é chamada uma ou 
duas vezes por exec, possivelmente para carregar o segmento de texto e sempre para carregar 
o segmento de dados. Em vez de apenas ler o arquivo, bloco por bloco, e depois copiar os 
blocos para o usuário, é usado um truque para permitir que o sistema de arquivos carregue o 
segmento inteiro diretamente no espaço de usuário. Na verdade, a chamada é decodificada 
pelo sistema de arquivos de uma maneira ligeiramente especial, para que pareça ser uma lei- 
tura do segmento inteiro para o processo de usuário em si. Apenas algumas linhas no início 
da rotina de leitura do sistema de arquivos sabem que uma artimanha está acontecendo aqui. 
A carga é sensivelmente acelerada por essa manobra. 

A última função em exec.c é find share (linha 19256). Ela procura um processo que 
possa compartilhar texto, comparando os tempos do i-node, do dispositivo e de modificação 
do arquivo a ser executado com os dos processos existentes. Essa é apenas uma pesquisa sim- 
ples dos campos apropriados em mproc. É claro que ela deve ignorar o processo em nome do 
qual a pesquisa está sendo feita. 


Implementação de BRK 


Conforme acabamos de ver, o modelo básico de memória usado pelo MINIX 3 é muito sim- 
ples: ao ser criado, cada processo recebe uma alocação adjacente para seus dados e sua pilha. 
Ele nunca é movido na memória, nunca cresce e nunca diminui. Tudo que pode acontecer é 
que o segmento de dados pode ir consumindo a lacuna a partir de baixo para cima e a pilha no 
sentido contrário. Sob essas circunstâncias, a implementação da chamada de brk em break.c 
é particularmente fácil. Ela consiste em verificar se os novos tamanhos são viáveis e, então, 
atualizar as tabelas para refleti-los. 

A função de nível superior é do brk (linha 19328), mas a maior parte do trabalho é 
feito em adjust (linha 19361). Esta última verifica se os segmentos de pilha e de dados se 
colidem, sobrepondo-se. Se colidiram, a chamada de brk não poderá ser executada, mas 
o processo não será eliminado imediatamente. Um fator de segurança, SAFETY BYTES, 
é adicionado no topo do segmento de dados, antes de fazer o teste, para que (espera-se) a 
decisão de que a pilha cresceu demais possa ser tomada enquanto ainda há espaço suficiente 
nela para o processo continuar por um pouco mais de tempo. Ele recebe o controle de volta 
(com uma mensagem de erro), para que possa imprimir as mensagens apropriadas e desligar 
normalmente. 

Note que SAFETY BYTES e SAFETY CLICKS são definidos usando declarações 
tdefine no meio da função (linha 19393). Esse uso é bastante incomum; normalmente tais 
definições aparecem no início dos arquivos ou em arquivos de cabeçalho separados. O co- 
mentário associado revela que o programador achou difícil decidir-se sobre o tamanho do 
fator de segurança. Sem dúvida, essa definição foi feita dessa maneira para chamar a aten- 
ção e, talvez, para estimular mais experiências. 

A base do segmento de dados é constante; portanto, se adjust tiver de ajustar o segmen- 
to de dados, tudo que fará será atualizar o campo de comprimento. A pilha cresce para baixo, 
a partir de um ponto final fixo; portanto, se adjust também notar que o ponteiro de pilha, que é 
fornecido a ela como parâmetro, cresceu além do segmento de pilha (para um endereço mais 
baixo), tanto a origem como o tamanho serão atualizados. 
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4.8.6 Implementação do tratamento de sinais 
Oito chamadas de sistema do POSIX estão relacionadas com sinais. Elas estão resumidas 
na Figura 4-47. Essas chamadas de sistema, assim como os sinais em si, são processadas no 
arquivo signal.c. 


Chamada de sistema | Objetivo 

sigaction Modifica ação para sinal futuro 

sigprocmask Altera conjunto de sinais bloqueados 

kill Envia sinal para outro processo 

alarm Decorrido um tempo, envia sinal ALRM para si mesmo 
pause Suspende a si mesmo até a ocorrência de um sinal 
sigsuspend Altera conjunto de sinais bloqueados, então PAUSE 
sigpending Examina conjunto de sinais pendentes (bloqueados) 
sigreturn Limpeza após a rotina de tratamento de sinal 


Figura 4-47 Chamadas de sistema relacionadas aos sinais. 


A chamada de sistema sigaction suporta as funções sigaction e signal, as quais permi- 
tem que um processo altere o modo como responderá aos sinais. Sigaction é exigida pelo 
POSIX e é a chamada preferida para a maioria dos propósitos, mas a função de biblioteca 
signal é exigida pela linguagem C Standard e os programas que precisam ser portados para 
sistemas que não são POSIX devem ser escritos fazendo uso dela. O código de do sigaction 
(linha 19544) começa verificando se um o número de sinal é válido e se a chamada não é uma 
tentativa de alterar a ação para um sinal sigkill (linhas 19550 e 19551). (Não é permitido igno- 
rar, capturar nem bloquear sigkill. Sigkill é a maneira final pela qual um usuário pode controlar 
seus processos e pela qual um gerente de sistema pode controlar seus usuários.) Sigaction é 
chamada com ponteiros para uma estrutura sigaction, sig osa, a qual recebe os atributos de 
sinal antigos que estavam em vigor antes da chamada, e para outra estrutura assim, sig nsa, 
contendo o novo conjunto de atributos. 

O primeiro passo é chamar a tarefa de sistema para copiar os atributos correntes na 
estrutura apontada por sig osa. Sigaction pode ser chamada com um ponteiro NULL em 
sig nsa, para examinar os atributos de sinal antigos sem alterá-los. Nesse caso, do sigaction 
retorna imediatamente (linha 19560). Se sig nsa não for NULL, a estrutura que define a nova 
ação do sinal será copiada no espaço do PM. 

O código nas linhas 19567 a 19585 modifica os mapas de bits mp catch, mp ignore e 
mp. sigpending, dependendo se a nova ação vai ignorar o sinal, usar a rotina de tratamento 
padrão ou capturar o sinal. O campo sa handler da estrutura sigaction é usado para passar 
um ponteiro para a função a ser executada, se um sinal precisar ser capturado ou um dos 
códigos especiais SIG IGN ou SIG DFL, cujos significados devem ser claros se você enten- 
deu o procedimento de tratamento de sinal do padrão POSIX discutidos anteriormente. Um 
código especial, próprio do MINIX 3, SIG MESS, também é possível; isso será explicado 
a seguir. 

As funções de biblioteca sigaddset e sigdelset são usadas para modificar os mapas de 
bits do sinal, embora as ações sejam operações de manipulação de bit elementares que po- 
deriam ter sido implementadas através de simples macros. Entretanto, essas funções são exi- 
gidas pelo padrão POSIX para tornar os programas que as utilizam facilmente portáveis, 
mesmo para sistemas nos quais a quantidade de sinais ultrapasse o número de bits disponíveis 
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em um valor inteiro. O uso das funções de biblioteca ajuda a tornar o próprio MINIX 3 facil- 
mente portável para diferentes arquiteturas. 

Mencionamos um caso especial anteriormente. O código SIG MESS, detectado na li- 
nha 19576, está disponível apenas para processos privilegiados (de sistema). Tais processos 
normalmente são bloqueados, esperando por mensagens de requisição. Assim, o método nor- 
mal de recepção de sinal, no qual o PM solicita ao núcleo para que coloque um quadro de 
sinal na pilha do destinatário, será retardado até que uma mensagem desperte o destinatário. 
Um código SIG MESS diz ao PM para que envie uma mensagem de notificação, a qual tem 
prioridade mais alta do que as mensagens normais. Uma mensagem de notificação contém 
como argumento o conjunto de sinais pendentes, permitindo que vários sinais sejam passados 
em uma única mensagem. 

Finalmente, são preenchidos os outros campos relacionados com sinal na parte do PM 
da tabela de processos. Para cada sinal em potencial existe um mapa de bits, o sa mask, que 
define quais sinais devem ser bloqueados enquanto uma rotina de tratamento para esse sinal 
está em execução. Para cada sinal também existe um ponteiro, sa handler. Ele pode conter 
um ponteiro para a função de tratamento; ou valores especiais para indicar se o sinal deve 
ser ignorado, tratado da maneira padrão ou usado para gerar uma mensagem. O endereço da 
rotina de biblioteca que ativa sigreturn quando a rotina de tratamento termina é armazenado 
em mp sigreturn. Esse endereço é um dos campos da mensagem recebida pelo PM. 

O POSIX permite que um processo manipule seu próprio tratamento de sinal, mesmo 
enquanto está dentro de uma rotina de tratamento de sinal. Isso pode ser usado para alterar 
a ação a ser realizada para sinais subsegiientes, enquanto um sinal está sendo tratado, e en- 
tão, restaurar o conjunto de ações normais. O próximo grupo de chamadas de sistema su- 
porta esses recursos de manipulação de sinal. Sigpending é manipulada por do sigpending 
(linha 19597), a qual retorna o mapa de bits mp sigpending, para que um processo possa 
determinar se possui sinais pendentes. Sigprocmask, manipulada por do sigprocmask, re- 
torna o conjunto de sinais que estão correntemente bloqueados e também pode ser usada 
para mudar o estado de um sinal do conjunto ou para substituir o conjunto inteiro por outro 
novo. Quando um sinal é desbloqueado é um momento adequado para verificar sinais pen- 
dentes e isso é feito por chamadas para check pending na linha 19635 e na linha 19641. 
Do sigsuspend (linha 19657) executa a chamada de sistema sigsuspend. Essa chamada 
suspende um processo até que um sinal seja recebido. Assim como as outras funções que 
discutimos aqui, ela manipula mapas de bits. Ela também configura o bit sigsuspended em 
mp flags, que é tudo que é necessário para evitar a execução do processo. Novamente, esse 
é um bom momento para fazer uma chamada para check pending. Finalmente, do sigreturn 
manipula sigreturn, que é usada para retornar de uma rotina de tratamento personalizada. Ela 
restaura o contexto de sinal que existia quando a rotina de tratamento foi iniciada e também 
chama check pending na linha 19682. 

Quando um processo de usuário, como o comando Kill, ativa a chamada de sistema kill, 
a função do kill do PM (linha 19689) é ativada. Uma única chamada para kill pode exigir o 
envio de sinais para um grupo de vários processos e do kill apenas chama check sig, que 
verifica a tabela de processos inteira em busca de possíveis destinatários. 

Alguns sinais, como sigint, são originados no próprio núcleo. Ksig pending (linha 
19699) é gerado quando uma mensagem do núcleo sobre sinais pendentes é enviada para o 
PM. Pode haver mais de um processo com sinais pendentes; portanto, o laço nas linhas 19714 
a 19722 solicita repetidamente um sinal pendente para a tarefa de sistema, passa o sinal para 
handle sig e, então, informa à tarefa de sistema que terminou, até que não haja mais proces- 
sos com sinais pendentes. As mensagens vêm com um mapa de bits, permitindo que o núcleo 
gere vários sinais com uma só mensagem. A próxima função, handle sig, processa o mapa de 
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bits, um bit por vez, nas linhas 19750 a 19763. Alguns sinais do núcleo precisam de atenção 
especial: o ID de processo é alterado em alguns casos, para fazer o sinal ser enviado para um 
grupo de processos (linhas 19753 a 19757). Caso contrário, cada bit de ativação resulta em 
uma chamada para check sig, exatamente como em do. ill. 


Alarmes e temporizadores 


A chamada de sistema alarm é manipulada por do alarm (linha 19769). Ela chama a função 
seguinte, set alarm, que é uma função a parte porque também é usada para desativar um tem- 
porizador quando um processo termina com um temporizador ainda ativo. Isso é feito cha- 
mando-se set alarm com um tempo de alarme igual a zero. Set alarm faz seu trabalho com 
temporizadores mantidos dentro do gerenciador de processos. Primeiramente, ela determina 
se um temporizador já está ativo em nome do processo solicitante e, se assim for, se ele ex- 
pirou, para que a chamada de sistema possa retornar o tempo (em segundos) restante em um 
alarme anterior ou zero, se nenhum temporizador foi configurado. Um comentário dentro do 
código explica alguns problemas no tratamento de tempos longos. Um código “muito sujo”, 
na linha 19918, multiplica o argumento da chamada (um tempo, em segundos) pela constante 
HZ (o número de tiques de relógio por segundo), para obter um tempo em unidades de tique. 
Três conversões são necessárias para transformar o resultado no tipo de dados clock t correto. 
Então, na linha seguinte, o cálculo é invertido, com conversões de tiques de clock t para 
unsigned long. O resultado é comparado com uma conversão do argumento do tempo de 
alarme original para unsigned long. Se eles não forem iguais, isso significa que o tempo 
solicitado resultou em um número que estava fora do intervalo de um dos tipos de dados 
usados e é substituído por um valor que significa “nunca”. Finalmente, pm set timer ou 
pm. cancel timer é chamada para adicionar ou remover um temporizador da fila de tem- 
porizadores do gerenciador de processos. O principal argumento da primeira chamada é 
cause sigalarm, a função de cão de guarda a ser executada quando o temporizador expirar. 

Toda interação com o temporizador mantida no espaço de núcleo é ocultada nas chama- 
das para as rotinas pm XXX timer. Toda requisição de alarme que culmina na sua ocorrência 
resultará em uma requisição para configurar um temporizador no espaço de núcleo. A única 
exceção seria se ocorresse mais de uma requisição de tempo limite exatamente ao mesmo 
tempo. Entretanto, os processos podem cancelar seus alarmes ou terminar antes que eles ex- 
pirem. Uma chamada de núcleo para solicitar a configuração de um temporizador no espaço 
de núcleo só precisa ser feita quando há uma alteração no temporizador no início da fila de 
temporizadores do gerenciador de processos. 

No momento da expiração de um temporizador da fila de temporizadores do espaço de 
núcleo, que foi configurado em nome do PM, a tarefa de sistema anuncia o fato enviando ao 
PM uma mensagem de notificação, detectada como o tipo SYN ALARM pelo laço principal 
do PM. Isso resulta em uma chamada para pm expire timers, que, em última análise, resulta 
na execução da função seguinte, cause sigalrm. 

Cause sigalarm (linha 19935) é a função de cão de guarda, mencionada anteriormen- 
te. Ela recebe o número do processo a ser sinalizado, verifica alguns flags, desativa o flag 
ALARM ON e chama check sig para enviar o sinal SIGALRM. 

A ação padrão do sinal SIGALRM é eliminar o processo, se não for capturado. Se o sinal 
SIGALRM precisa ser capturado, uma rotina de tratamento deve ser instalada por sigaction. A 
Figura 4-48 mostra a seqiiência de eventos completa de um sinal SIGALRM com uma rotina 
de tratamento personalizada. A figura mostra que ocorrem três sequências de mensagens. Pri- 
meiramente, na mensagem (1), o usuário executa uma chamada alarm por meio de uma men- 
sagem para o PM. Nesse ponto, o gerenciador de processos configura um temporizador na fila 
de temporizadores que mantém para processos de usuário e confirma com a mensagem (2). 
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Nada mais pode acontecer, por enquanto. Quando o temporizador dessa requisição chegar no 
início da fila de temporizadores do PM, porque os temporizadores que estavam na frente dele 
expiraram ou foram cancelados, a mensagem (3) será enviada para a tarefa de sistema, para 
que ela configure um novo temporizador para o gerenciador de processos, e é confirmado pela 
mensagem (4). Novamente, passará algum tempo antes que algo mais aconteça. Mas depois 
que esse temporizador chegar no início da fila de temporizadores, a rotina de tratamento de 
interrupção de relógio verá que ele expirou. As mensagens restantes da sequência seguirão ra- 
pidamente. A rotina de tratamento de interrupção de relógio envia uma mensagem HARD INT 
(5) para a tarefa de relógio, que a faz ser executada e atualizar seus temporizadores. A função 
de cão de guarda do temporizador, cause alarm, inicia a mensagem (6), uma notificação para 
o PM. Agora, o PM atualiza seus temporizadores e, após determinar, a partir de sua parte da 
tabela de processos, que uma rotina de tratamento está instalada para SIGALRM no processo 
de destino, envia a mensagem (7) para a tarefa de sistema, para que sejam feitas as manipu- 
lações de pilha necessárias para enviar o sinal para o processo do usuário. Isso é confirmado 
pela mensagem (8). O processo do usuário será escalonado, executará a rotina de tratamento 
e, então, fará uma chamada de sigreturn (9) para o gerenciador de processos. Então, o geren- 
ciador de processos envia a mensagem (10) para a tarefa de sistema para completar a limpeza 
e isso é confirmado pela mensagem (11). Nesse diagrama não aparece outro par de mensa- 
gens do PM para a tarefa de sistema, para obter o tempo de funcionamento, enviadas antes da 
mensagem (3). 


Camada 
Rotina de 4 


tratamento 
de ALRM 


4 e 
| Hardware E Ea Relógio 


Eq 


Figura 4-48 Mensagens para um alarme. As mais importantes são: (1) O usuário executa 
uma chamada alarm. (3) O PM pede à tarefa de sistema para que configure o temporizador. 
(6) O relógio diz ao PM que o tempo expirou. (7) O PM solicita sinal para o usuário. (9) A 
rotina de tratamento termina com chamada para sigreturn. Veja os detalhes no texto. 


A próxima função, do pause, trata da chamada de sistema pause (linha 19853). Na 
verdade ela não está relacionada com alarmes e temporizadores, embora possa ser usada 
em um programa para suspender a execução até que um alarme (ou algum outro sinal) seja 
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recebido. Tudo que é necessário é ativar um bit e retornar o código SUSPEND, o qual faz o 
laço principal do PM deixar de responder, mantendo assim o processo que fez a chamada 
bloqueado. O núcleo nem mesmo precisa ser informado, pois sabe que o processo que fez a 
chamada está bloqueado. 


Funções de suporte para sinais 


Várias funções de suporte em signal.c foram mencionadas de passagem. Vamos vê-las agora 
com mais detalhes. A mais importante delas é sig proc (linha 19864), que realmente envia 
um sinal. Primeiro, são feitos vários testes. Tentativas de envio para processos eliminados 
ou zumbis são problemas sérios que causam uma situação de pânico em um sistema (linhas 
19889 a 19893). Um processo que está correntemente sendo rastreado (tracing) é interrom- 
pido ao ser sinalizado (linhas 19894 a 19899). Se o sinal deve ser ignorado, o trabalho de 
sig proc termina na linha 19902. Essa é a ação padrão para alguns sinais; por exemplo, os 
sinais que são obrigados a existir pelo POSIX, mas que não precisam ser (e não são) supor- 
tados pelo MINIX 3. Se o sinal é bloqueado, a única ação que precisa ser executada é ativar 
um bit no mapa de bits mp sigpending desse processo. O teste principal (linha 19910) serve 
para distinguir processos que habilitaram a captura desses sinais daqueles que não o fizeram. 
Com a exceção dos sinais que são convertidos em mensagens a serem enviadas para serviços 
do sistema, todas as outras considerações especiais foram eliminadas por esse ponto e um 
processo que não pode capturar o sinal deve ser terminado. 

Primeiramente, veremos o processamento de sinais que podem ser capturados (linhas 
19911 a 19950). É construída uma mensagem para ser enviada ao núcleo, algumas partes da 
mensagem são cópias das informações presentes na parte da tabela de processos que está no 
PM. Se o processo a ser sinalizado foi suspenso anteriormente por sigsuspend, a máscara de 
sinal que foi salva no momento da suspensão é incluída na mensagem; caso contrário, será 
incluída a máscara de sinal corrente (linha 19914). Outros itens incluídos na mensagem são 
endereços do espaço do processo sinalizado, como: a rotina de tratamento de sinal, a rotina 
de biblioteca sigreturn a ser chamada no término da rotina de tratamento e o ponteiro de 
pilha corrente. 

Em seguida, é alocado espaço na pilha do processo. A Figura 4-49 mostra a estrutura 
colocada na pilha. A parte sigcontext é colocada na pilha para preservá-la para posterior res- 
tauração, pois a estrutura correspondente na tabela de processos em si é alterada na prepara- 
ção para execução da rotina de tratamento de sinal. A parte sigframe fornece um endereço de 
retorno para a rotina de tratamento de sinal e os dados necessários por sigreturn para concluir 
a restauração do estado do processo, quando a rotina de tratamento terminar. O endereço de 
retorno e o ponteiro de quadro não são usados em nenhuma parte do MINIX 3. Eles existem 
para lubridiar um depurador, caso alguém tente rastrear a execução de uma rotina de trata- 
mento de sinal. 

A estrutura a ser colocada na pilha do processo sinalizado é muito grande. O código nas 
linhas 19923 e 19924 reserva espaço para ela, após o qual uma chamada para adjust faz um 
teste para ver se há espaço suficiente na pilha do processo. Se não houver espaço suficiente 
na pilha, o processo será eliminado desviando para o rótulo doterminate, via comando goto, 
raramente utilizado, da linguagem C (linhas 19926 e 19927). 

A chamada para adjust tem um problema em potencial. Lembre-se, de nossa discus- 
são sobre a implementação de brk, que adjust retorna um erro se a pilha estiver dentro de 
SAFETY BYTES de execução no segmento de dados. A margem de erro extra é fornecida 
porque a validade da pilha só pode ser verificada ocasionalmente pelo software. Essa margem 
de erro provavelmente é excessiva no caso presente, pois se sabe exatamente quanto espaço 
é necessário na pilha para o sinal; e é necessário espaço adicional apenas para a rotina de tra- 
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Figura 4-49 As estruturas sigcontext e sigframe colocadas na pilha para preparar uma rotina 
de tratamento de sinal. Os registradores do processador são uma cópia do quadro de pilha 
usado durante uma troca de contexto. 


tamento de sinal, presumivelmente uma função relativamente simples. É possível que alguns 
processos sejam desnecessariamente terminados porque a chamada para adjust falha. Isso 
certamente é melhor do que ter programas que falham misteriosamente em outras ocasiões, 
mas uma otimização desses testes pode ser viável em algum momento no futuro. 

Se há espaço suficiente na pilha para a estrutura, mais dois flags são verificados. O flag 
FS_NODEFER indica se o processo sinalizado deve bloquear mais sinais do mesmo tipo, 
enquanto trata uma ocorrência desse sinal. O flag FS_RESETHAND informa se a rotina de 
tratamento de sinal deve ser reconfigurada ao receber esse sinal. (Isso proporciona uma simu- 
lação fiel da antiga chamada signal. Embora esse “recurso” seja freqüentemente considerado 
uma falha na chamada antiga, o suporte de recursos antigos exige também o suporte para suas 
falhas.) Então, o núcleo é notificado, usando a chamada de núcleo sys_sigsend (linha 19940) 
para colocar a estrutura sigframe na pilha. Finalmente, o bit indicando que existe um sinal 
pendente é zerado e unpause é chamada para terminar qualquer chamada de sistema em que 
o processo possa estar suspenso. Na próxima vez que o processo sinalizado for executado, a 
rotina de tratamento de sinal também será. Se, por algum motivo, todos os testes anteriores 
falharem, o PM entrará em uma situação de pânico (linha 19949). 

A exceção mencionada anteriormente — sinais convertidos em mensagens para ser- 
viços do sistema — é testada na linha 19951 e executada pela chamada de núcleo sys_kill 
que aparece em seguida. Isso faz a tarefa de sistema enviar uma mensagem de notificação 
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para o processo sinalizado. Lembre-se de que, ao contrário da maioria das outras notifica- 
ções, uma notificação da tarefa de sistema carrega uma carga útil, além das informações 
básicas sobre sua origem e uma indicação de tempo. Ela também transmite um mapa de 
bits de sinais para que o processo de sistema sinalizado conheça todos os sinais pendentes. 
Se a chamada sys kill falhar, o PM entrará em uma situação de pânico. Se ela tiver êxito, 
sig proc retornará (linha 19954). Se o teste na linha 19951 falhasse, a execução iria para o 
rótulo doterminate. 

Agora, vamos ver o código de término, marcado pelo rótulo doterminate (linha 19957). 
O comando goto é a maneira mais fácil de tratar da possível falha da chamada para adjust. 
Aqui são processados sinais que, por um motivo ou outro, não podem ou não devem ser cap- 
turados. É possível que o sinal deva ser ignorado, situação em que sig proc apenas retorna. 
Caso contrário, o processo deve ser terminado. A única questão é se também é necessário ge- 
rar um core dump. Finalmente, o processo é terminado como se tivesse terminado, por meio 
de uma chamada para pm. exit (linha 19967). 

Check sig (linha 19973) é onde o PM verifica se um sinal pode ser enviado. A chamada 


kill(O, sig); 


faz o sinal indicado ser enviado para todos os processos no grupo do processo que fez a cha- 
mada (isto é, todos os processos iniciados a partir do mesmo terminal). Os sinais originados 
no núcleo e a chamada de sistema reboot também podem afetar vários processos. Por isso, 
check sig faz um laço nas linhas 19996 a 20026, para percorrer a tabela de processos a fim 
de localizar todos os processos para os quais um sinal deve ser enviado. O laço contém um 
grande número de testes. Somente se todos eles forem passados é que o sinal será enviado, 
pela chamada de sig proc na linha 20023. 

Check pending (linha 20036) é outra função importante, chamada várias vezes no 
código que acabamos de examinar. Ela faz um laço por todos os bits no mapa de bits 
mp sigpending, para o processo referido por do sigmask, do sigreturn ou do sigsuspend, 
para ver se algum sinal bloqueado foi desbloqueado. Ela chama sig proc para enviar o pri- 
meiro sinal desbloqueado pendente que encontrar. Como todas as rotinas de tratamento de 
sinal finalmente causam a execução de do sigreturn, esse código é suficiente para enviar 
todos os sinais desmascarados pendentes. 

A função unpause (linha 20065) está relacionada com os sinais enviados para processos 
suspensos em chamadas pause, wait, read, write ou sigsuspend. Pause, wait e sigsuspend 
podem ser verificadas consultando-se a parte do PM da tabela de processos, mas se nenhuma 
delas for encontrada, deverá ser solicitado ao sistema de arquivos para que utilize sua própria 
função do unpause para verificar um possível problema em read ou write. Em cada caso, a 
ação é a mesma: uma resposta de erro é enviada para a chamada que está esperando e o bit de 
flag correspondente à causa da espera é zerado para que o processo possa retomar a execução 
e processar o sinal. 

A última função nesse arquivo é dump core (linha 20093), que escreve core dumps 
no disco. Um core dump consiste em um cabeçalho com informações sobre o tamanho dos 
segmentos ocupados por um processo, uma cópia de todas as informações de estado do pro- 
cesso, obtidas pela cópia das informações da tabela de processos do núcleo para o processo, 
e a imagem de memória de cada um dos segmentos. Um depurador pode interpretar essas 
informações para ajudar o programador a determinar o que deu errado durante uma execução 
do processo. 

O código para escrever o arquivo é simples. O problema em potencial mencionado na 
seção anterior surge novamente, mas de uma forma bastante diferente. Para garantir que o 
segmento de pilha registrado no core dump seja atualizado, adjust é chamada na linha 20120. 
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Essa chamada pode falhar por causa da margem de segurança incorporada. O sucesso da cha- 
mada não é verificado por dump core; portanto o core dump será gerado de qualquer forma, 
mas dentro do arquivo, as informações sobre a pilha podem estar incorretas. 


Funções de suporte para temporizadores 


O gerenciador de processos do MINIX 3 manipula solicitações de alarmes de processos de 
usuário, os quais não podem entrar diretamente em contato com o núcleo nem com a tarefa de 
sistema. Todos os detalhes do escalonamento de um alarme na tarefa de relógio ficam ocultos 
por trás dessa interface. Somente processos de sistema podem configurar um temporizador de 
alarme no núcleo. O suporte para isso é fornecido no arquivo timers.c (linha 20200). 

O gerenciador de processos mantém uma lista de solicitações de alarmes e pede à tarefa 
de sistema para que o notifique quando for hora de um alarme. Quando um alarme vem do 
núcleo, o gerenciador de processos passa para o processo que deve recebê-lo. 

Três funções são fornecidas aqui para suportar temporizadores. Pm set timer configura 
um temporizador e o adiciona na lista de temporizadores do PM, pm expire timer verifica a 
existência de temporizadores expirados e pm cancel timer remove um temporizador da lista 
do PM. Todas as três tiram proveito de funções existentes na biblioteca de temporizadores, 
declarada em include/timers.h. A função Pm set timer chama tmrs. settimer, pm expire ti- 
mer chama tmrs exptimers e pm cancel timer chama tmrs clrtimers. Todas elas gerenciam 
a atividade de percorrer uma lista encadeada e inserir ou remover um item, conforme for 
exigido. Somente quando um item é inserido ou removido do início da fila, é que se torna 
necessário envolver a tarefa de sistema para ajustar a fila de temporizadores que está em espa- 
ço de núcleo. Para tanto, cada uma das funções pm XXX timer usa uma chamada de núcleo 
sys setalarm. 


Implementação de outras chamadas de sistema 


O gerenciador de processos manipula três chamadas de sistema que envolvem tempo, em 
time.c: time, stime e times. Elas estão resumidas na Figura 4-50. 


Chamada Função 

time Obtém o tempo corrente real e o tempo de funcionamento 
(uptime), em segundos 

stime Configura o relógio de tempo real 

times Obtém os tempos de contabilização do processo 


Figura 4-50 Três chamadas de sistema envolvendo tempo. 


O tempo real é mantido pela tarefa de relógio dentro do núcleo, mas ela em si não troca 
mensagens com nenhum processo, exceto a tarefa de sistema. Como conseqgiiência, a única 
maneira de obter ou configurar o tempo real é enviar uma mensagem para a tarefa de sistema. 
É isso, na verdade, que do time (linha 20320) e do stime (linha 20341) fazem. O tempo real 
é medido em segundos decorridos desde 1º de janeiro de 1970. 

As informações de contabilização também são mantidas pelo núcleo para cada proces- 
so. Cada tique de relógio é cobrado de algum processo. O núcleo não sabe sobre os relacio- 
namentos pai-filho; portanto, ele recorre ao gerenciador de processos para acumular informa- 
ções de tempo dos filhos de um processo. Quando um filho sai, seus tempos são acumulados 
na entrada do pai na tabela de processos que faz parte do PM. Do times (linha 20366) recu- 
pera da tarefa de sistema a utilização de tempo de um processo pai, com uma chamada de 
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núcleo sys times e, depois, cria uma mensagem de resposta com o tempo de usuário e de 
sistema cobrado dos filhos. 

O arquivo getset.c contém uma única função, do getset (linha 20415), a qual executa 
sete chamadas de sistema do PM exigidas pelo POSIX. Elas aparecem na Figura 4-51. Todas 
são tão simples que não merecem uma função inteira para cada uma. As chamadas de getuid 
e getgid retornam ambas o UID ou o GID real e efetivo. 

Configurar o uid ou o gid é ligeiramente mais complexo do que apenas ler. Precisa ser 
feita uma verificação para ver se o processo que fez a chamada está autorizado a configurá- 
los. Se o processo que fez a chamada for autorizado, o sistema de arquivos deverá ser infor- 
mado do novo uid ou gid, pois a proteção do arquivo depende disso. A chamada de setsid 
cria uma nova sessão e um processo que já é líder de um grupo de processos não pode fazer 
isso. O teste na linha 20463 verifica essa condição. O sistema de arquivos conclui a tarefa de 
transformar um processo em líder de sessão sem nenhum terminal de controle. 


Chamada de sistema Descrição 

getuid Retorna o UID real e efetivo 

getgid Retorna o GID real e efetivo 

getpid Retorna os PIDs do processo e de seu pai 

setuid Configura o UID real e efetivo do processo que fez a chamada 
setgid Configura o GID real e efetivo do processo que fez a chamada 
setsid Cria uma nova sessão, retorna o PID 

getpgrp Retorna a ID do grupo de processos 


Figura 4-51 As chamadas de sistema suportadas em servers/pm/getset.c. 


Em contraste com as chamadas de sistema consideradas até aqui, neste capítulo, as 
chamadas em misc.c não são exigidas pelo POSIX. Essas chamadas são necessárias porque 
os drivers de dispositivo e servidores no espaço dd usuário do MINIX 3 precisam de suporte 
para comunicação com o núcleo que não é necessário em sistemas operacionais monolíticos. 
A Figura 4-52 mostra essas chamadas e seus objetivos. 


Chamada de sistema Descrição 

do allocmem Aloca uma área de memória 

do freemem Libera uma área de memória 

do getsysinfo Obtém informações sobre o PM a partir do núcleo 

do getprocnr Obtém o índice para a tabela de processos a partir do PID ou 
do nome 

do reboot Elimina todos os processos, informa o FS e o núcleo 

do getsetpriority Obtém ou configura a prioridade do sistema 

do svrctrl Transforma um processo em servidor 


Figura 4-52 Chamadas de sistema de propósito especial do MINIX 3 em servers/pm/misc.c. 


As duas primeiras são manipuladas inteiramente pelo PM. do allocmem lê a requi- 
sição de uma mensagem recebida, converte para unidades de click e chama alloc mem. 
Isso é usado, por exemplo, pelo driver de memória para alocar memória do disco de RAM. 
Do freemem é semelhante, mas chama free mem. 
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As chamadas seguintes normalmente precisam de ajuda de outras partes do sistema. 
Elas podem ser consideradas como interfaces para a tarefa de sistema. Do getsysinfo (linha 
20554) pode fazer várias coisas, dependendo da requisição presente na mensagem recebida. 
Ela pode chamar a tarefa de sistema para obter informações sobre o núcleo, contidas na 
estrutura kinfo (definida no arquivo include/minix/type.h). Ela também pode ser usada para 
fornecer o endereço da parte do PM em si da tabela de processos ou uma cópia da tabela de 
processos inteira para outro processo, mediante solicitação. A última ação é executada por 
uma chamada para sys. datacopy (linha 20582). Do getprocnr pode encontrar um índice para 
a tabela de processos em sua própria seção, se for dado o PID, e chama a tarefa de sistema 
para solicitar auxílio, caso tenha apenas o nome do processo de destino para trabalhar. 

As duas chamadas seguintes, embora não sejam exigidas pelo POSIX, são provavel- 
mente encontradas em alguma forma na maioria dos sistemas do tipo UNIX. Do reboot envia 
um sinal KILL para todos os processos e diz ao sistema de arquivos para que fique pronto para 
uma reinicialização. Somente depois que o sistema de arquivos se sincronizar é que o núcleo 
será notificado com uma chamada de sys. abort (linha 20667). Uma reinicialização pode ser 
o resultado de uma situação de pânico ou um pedido do superusuário para causar uma parada 
ou reiniciar, e o núcleo precisa saber qual caso se aplica. Do getsetpriority suporta o famoso 
utilitário nice do UNIX, o qual permite a um usuário reduzir a prioridade de um processo para 
ser um bom vizinho para outros processos (possivelmente os dele próprio). Essa chamada 
é usada pelo sistema MINIX 3 principalmente para fornecer um controle refinado sobre as 
prioridades relativas dos componentes do sistema. Um dispositivo de rede ou de disco que 
precisa manipular um fluxo de dados com uma taxa alta pode ter prioridade sobre outro que 
recebe dados mais lentamente, como o teclado. Além disso, um processo de alta prioridade 
que esteja em um laço, e impedindo que outros processos sejam executados, pode ter sua 
prioridade diminuída temporariamente. A alteração da prioridade é feita pondo o processo 
em uma fila de prioridade mais baixa (ou mais alta), conforme descrito na discussão sobre 
implementação do escalonamento, no Capítulo 2. Quando isso é feito pelo escalonador no 
núcleo, não há necessidade de envolver o PM, é claro, mas um processo normal precisa usar 
uma chamada de sistema. No PM, isso é apenas uma questão de ler o valor corrente retornado 
em uma mensagem ou gerar uma mensagem com um novo valor. Uma chamada de núcleo, 
Sys nice envia o novo valor para a tarefa de sistema. 

A última função em misc.c é do svrctl. Correntemente, ela é usada para habilitar e 
desabilitar o swapping. Uma vez atendidas por essa chamada, outras funções devem ser im- 
plementadas no servidor de reencarnação. 

A última chamada de sistema que consideraremos neste capítulo é ptrace, manipulada 
por trace.c. Esse arquivo não está listado no Apêndice B, mas pode ser encontrado no CD- 
ROM e no site web do MINIX 3. Ptrace é usada por programas de depuração. O parâmetro 
dessa chamada pode ser um de 11 comandos. Eles estão mostrados na Figura 4-53. No PM, 
do trace processa quatro deles: 7 OK, T RESUME, T EXIT e T STEP. As requisições para 
entrar e sair de rastreamento são completados aqui. Todos os outros comandos são passados 
para a tarefa de sistema, a qual tem acesso à parte do núcleo da tabela de processos. Isso é 
feito chamando-se a função de biblioteca sys trace. São fornecidas duas funções de suporte 
para rastreamento. Find proc procura o processo a ser rastreado na tabela de processos e 
stop proc interrompe um processo rastreado, quando ele é sinalizado. 


Utilitários de gerenciamento de memória 


Concluiremos este capítulo descrevendo sucintamente mais dois arquivos que fornecem fun- 
ções de suporte para o gerenciador de processos. São eles alloc.c e utility.c. Como os detalhes 
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Comando Descrição 
T STOP Interrompe o processo 
T OK Ativa o rastreamento pelo pai desse processo 
T GETINS Retorna valor do espaço de texto (instrução) 
T GETDATA Retorna valor do espaço de dados 
T GETUSER Retorna valor da tabela de processos de usuário 
T SETINS Atribui valor no espaço de instrução 
T SETDATA Atribui valor no espaço de dados 
T SETUSER Atribui valor na tabela de processos de usuário 
T RESUME Retoma a execução 
T EXIT Termina 
T STEP Ativa o bit de rastreamento 


Figura 4-53 Comandos de depuração suportados por servers/pm/trace.c. 


internos desses arquivos não são discutidos aqui, eles não foram impressos no Apêndice B 
(para evitar que este livro, que já é grande, se tornasse ainda maior). Entretanto, estão dispo- 
níveis no CD-ROM e no site web do MINIX 3. 

Alloc.c é onde o sistema monitora quais partes da memória estão em uso e quais estão 
livres. Ele tem três pontos de entrada: 


1. alloc mem — solicita um bloco de memória de determinado tamanho. 
2. free mem — retorna memória que não é mais necessária. 


3. mem init — inicializa a lista de regiões de memória livres quando o PM começa a 
executar. 


Conforme dissemos anteriormente, alloc mem usa o algoritmo o primeiro que couber 
em uma lista de lacunas ordenada pelo endereço de memória. Ao encontrar uma lacuna gran- 
de demais, é alocado apenas o necessário e deixa o restante na lista de regiões livres, mas 
reduzida no tamanho pela quantidade tomada. Se for necessária a lacuna inteira, del slot é 
chamada para remover a entrada da lista de regiões livres. 

A tarefa de free mem é verificar se uma porção de memória recentemente liberada pode 
ser fusionada com lacunas de qualquer dos lados. Se puder, merge é chamada para unir as 
lacunas e atualizar as listas. 

Mem, init constrói a lista de regiões livres inicial, consistindo em toda a memória dis- 
ponível. 

O último arquivo a ser descrito é utility.c, que contém algumas funções variadas, usadas 
em diversos lugares no PM. Assim como alloc.c, utility.c não está listada no Apêndice B. 

Get free pid encontra um PID livre para um processo filho. Ela evita um problema 
que possivelmente poderia ocorrer. O valor de PID máximo é 30.000. Esse deve ser o valor 
máximo que pode estar em PID +. Esse valor foi escolhido para evitar problemas com alguns 
programas mais antigos que usam um tipo menor. Após atribuir, digamos, o PID 20 para um 
processo de duração muito longa, mais 30.000 processos poderiam ser criados e destruídos, 
e simplesmente incrementar uma variável sempre que um novo PID é necessário, voltando a 
zero quando o limite é atingido, se poderia chegar ao valor 20 novamente. Atribuir um PID 
que ainda está em uso seria um desastre (suponha que posteriormente alguém tentasse sina- 
lizar o processo 20). Uma variável contendo o último PID atribuído é incrementada e, se ela 
ultrapassar um valor máximo fixo, recomeça com o PID 2 (porque init sempre tem o PID 1). 
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Então, a tabela de processos inteira é pesquisada para garantir que o PID a ser atribuído ainda 
não esteja em uso. Se estiver em uso, o procedimento será repetido até que seja encontrado 
um PID livre. 

A função allowed verifica se determinado acesso é permitido a um arquivo. Por exem- 
plo, do exec precisa saber se um arquivo é executável. 

A função no sys nunca deve ser chamada. Ela é fornecida apenas para o caso de um 
usuário chamar o PM com um número de chamada de sistema inválido. 

Panic é chamada apenas quando o PM detectou um erro do qual não pode se recuperar. 
Ela relata o erro para a tarefa de sistema, a qual, então, interrompe o MINIX 3. Ela não deve 
ser chamada frequentemente. 

A próxima função em utility.c é tell fs, que constrói uma mensagem e a envia para o 
sistema de arquivos quando este precisa ser informado sobre eventos manipulados pelo PM. 

Find param é usada para analisar os parâmetros do monitor. Seu uso corrente é na 
extração de informações sobre a utilização de memória antes que o MINIX 3 seja carregado 
na memória, mas poderia ser usada para encontrar outras informações, caso houvesse neces- 
sidade. 

As duas funções seguintes nesse arquivo fornecem interfaces para a função de bi- 
blioteca sys getproc, a qual chama a tarefa de sistema para obter informações da parte do 
núcleo da tabela de processos. Sys getproc, por sua vez, é na verdade uma macro definida 
em include/minix/syslib.h, a qual passa parâmetros para a chamada de núcleo sys getinfo. 
Get mem map obtém o mapa de memória de um processo. Get stack ptr obtém o ponteiro de 
pilha. Ambas precisam de um número de processo, isto é, um índice para a tabela de processos, 
o qual não é o mesmo que um PID. A última função em utility.c é proc from pid, que fornece 
esse suporte — ela é chamada com um PID e retorna um índice para a tabela de processos. 


RESUMO 


Neste capítulo, examinamos o gerenciamento de memória, tanto em geral como no MINIX 3. 
Vimos que os sistemas mais simples não fazem swapping nem paginação. Uma vez que um 
programa é carregado na memória, ele permanece lá até terminar. Os sistemas embarcados 
normalmente funcionam assim, possivelmente até com o código na memória ROM. Alguns 
sistemas operacionais permitem apenas um processo por vez na memória, enquanto outros 
suportam multiprogramação. 

O passo seguinte é o swapping. Quando o swapping é usado, o sistema pode manipular 
mais processos do que tem de espaço disponível na memória. Os processos para os quais não 
há espaço são levados para o disco. O espaço livre na memória e no disco pode ser monitora- 
do com um mapa de bits ou com uma lista de lacunas. 

Os computadores mais avançados frequentemente têm alguma forma de memória vir- 
tual. Na forma mais simples, o espaço de endereçamento de cada processo é dividido em 
blocos de tamanho uniforme chamados de páginas, que podem ser colocados em qualquer 
quadro de página disponível na memória. Muitos algoritmos de substituição de página foram 
propostos. Dois dos mais conhecidos são o da segunda chance e do envelhecimento. Para 
fazer os sistemas de paginação funcionarem bem, escolher um algoritmo não é suficiente; 
é necessário dar atenção a questões como determinar o conjunto de trabalho, a política de 
alocação de memória e o tamanho de página. 

A segmentação ajuda na manipulação de estruturas de dados que mudam de tamanho 
durante a execução e simplifica a ligação e o compartilhamento. Ela também facilita oferecer 
proteção diferente para diferentes segmentos. Às vezes, a segmentação e a paginação são 
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combinadas para fornecer uma memória virtual bidimensional. O Pentium da Intel suporta 
segmentação e paginação. 

O gerenciamento de memória no MINIX 3 é simples. A memória é alocada quando um 
processo executa uma chamada de sistema fork ou exec. A memória assim alocada nunca é 
aumentada nem diminuída durante a vida do processo. Nos processadores Intel, existem dois 
modelos de memória usados pelo MINIX 3. Os programas pequenos podem ter instruções e 
dados no mesmo segmento de memória. Os programas maiores usam espaços de instrução 
e de dados separados (I e D separados). Os processos com espaços I e D separados podem 
compartilhar a parte de sua memória relativa ao texto; portanto, apenas memória de dados e 
de pilha devem ser alocados durante uma operação fork. Isso também pode ser verdade du- 
rante uma operação exec, caso outro processo já esteja usando o texto necessário para o novo 
programa. 

A maior parte do trabalho do PM não está ligada ao monitoramento da memória livre, 
o que ele faz usando uma lista de lacunas e o algoritmo o primeiro que couber, mas sim à 
execução das chamadas de sistema relacionadas ao gerenciamento de processos. Diversas 
chamadas de sistema suportam sinais POSIX e, como a ação padrão da maioria dos sinais é 
terminar o processo sinalizado, é apropriado manipulá-las no PM, o qual inicia o término de 
todos os processos. Várias chamadas de sistema não diretamente relacionadas com a memória 
também são manipuladas pelo PM, principalmente porque ele é menor do que o sistema de 
arquivos e, assim, foi mais conveniente colocá-las aqui. 


PROBLEMAS 


1. Um sistema de computador tem espaço suficiente para conter quatro programas em sua memória 
principal. Cada um desses programas fica ocioso metade do tempo, esperando por E/S. Que fração 
do tempo da CPU é desperdiçada? 


2. Considere um sistema com swapping no qual a memória consiste nos tamanhos de lacuna a seguir, 
pela ordem de memória: 10 KB, 4 KB, 20 KB, 18 KB, 7 KB, 9 KB, 12 KB e 15 KB. Qual lacuna é 
tomada para solicitações de segmento sucessivos de 


(a) 12 KB 
(b) 10 KB 
(c) 9KB 


para o algoritmo o primeiro que couber? Agora, repita a questão para o algoritmo o que melhor 
couber, o que pior couber e o próximo que couber. 


3. Um computador tem 1 GB de memória RAM alocada em unidades de 64 KB. Quantos KB serão 
necessários se um mapa de bits for usado para monitorar a memória livre? 


4. Agora, refaça a questão anterior usando uma lista de lacunas. Qual é a quantidade de memória 
necessária para a lista no melhor e no pior caso? Suponha que o sistema operacional ocupe os 512 
KB inferiores da memória. 


5. Qual é a diferença entre um endereço físico e um endereço virtual”? 


6. Usando o mapeamento de página da Figura 4-8, dê o endereço físico correspondente a cada um dos 
seguintes endereços virtuais: 


(a) 20 


(b) 4100 
(c) 8300 
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7. 


10. 


11. 


12. 


13. 


14. 


15. 


16. 


17. 


18. 


Na Figura 4-9, o campo de página do endereço virtual tem 4 bits e o campo de página do endereço 
físico tem 3 bits. Em geral, é permitido que o número de bits de página do endereço virtual seja me- 
nor, igual ou maior do que o número de bits de página do endereço físico? Discuta sua resposta. 


O processador Intel 8086 não suporta memória virtual. Contudo, algumas empresas chegaram a co- 
mercializar sistemas que continham uma CPU 8086 não modificada e faziam paginação. Faça uma 
suposição abalizada sobre como elas faziam isso. (Dica: pense sobre a posição lógica da MMU.) 


Se uma instrução demora 1 ns e uma falta de página demora mais n ns, dê uma fórmula para o 
tempo de instrução efetivo, se os erros de página ocorrem a cada k instruções. 


Uma máquina tem um espaço de endereçamento de 32 bits e uma página de 8 KB. A tabela de pá- 
ginas está inteiramente no hardware, com uma palavra de 32 bits por entrada. Quando um processo 
começa, a tabela de páginas é copiada no hardware a partir da memória, a uma taxa de uma palavra 
a cada 100 ns. Se cada processo executa por 100 ms (incluindo o tempo para carregar a tabela de 
páginas), que fração do tempo da CPU é dedicada ao carregamento das tabelas de página? 


Um computador com um endereçamento de 32 bits usa uma tabela de páginas de dois níveis. Os 
endereços virtuais são divididos em um campo de tabela de páginas de nível superior de 9 bits, um 
campo de tabela de páginas de segundo nível de 11 bits e um deslocamento. Qual é o tamanho das 
páginas e quantas existem no espaço de endereços? 


A seguir está a listagem de um pequeno programa em um pseudo-assembly para um computador 
com páginas de 512 bytes. O programa está localizado no endereço 1020 e seu ponteiro de pilha 
está em 8192 (a pilha cresce em direção a 0). Forneça a string de referência de página gerada por 
esse programa. Cada instrução ocupa 4 bytes (1 palavra) e tanto referências de instrução como de 
dados contam na string de referência. 


Carregar a palavra 6144 no registrador O 

Colocar o registrador 0 na pilha 

Chamar uma função em 5120, empilhando o endereço de retorno 
Subtrair a constante imediata 16 do ponteiro de pilha 

Comparar o parâmetro real com a constante imediata 4 

Pular se for igual a 5152 


Suponha que um endereço virtual de 32 bits seja dividido em quatro campos, a, b, c e d. Os três 
primeiros são usados por um sistema de tabela de páginas de três níveis. O quarto campo, d, é o 
deslocamento. O número de páginas depende dos tamanhos de todos os quatro campos? Se não 
depende, quais importam e quais não importam”? 


Um computador cujos processos têm 1024 páginas em seus espaços de endereçamento mantém 
suas tabelas de página na memória. A sobrecarga exigida para ler uma palavra da tabela de páginas 
é de 500 ns. Para reduzir essa sobrecarga, o computador tem um TLB, o qual contém 32 pares 
(página virtual, quadro de página físico), e pode fazer uma pesquisa em 100 ns. Qual é a taxa de 
acertos necessária para reduzir a sobrecarga média para 200 ns? 


O TLB no VAX não continha um bit R (referência). Essa omissão era apenas um artefato de seu 
tempo (anos 80) ou há algum outro motivo para sua ausência? 


Uma máquina tem endereços virtuais de 48 bits e endereços físicos de 32 bits. As páginas têm 
8 KB. Quantas entradas são necessárias para a tabela de páginas? 


Uma CPU RISC com endereços virtuais de 64 bits e 8 GB de memória RAM usa uma tabela de 
páginas invertida com páginas de 8 KB. Qual é o tamanho mínimo do TLB? 


Um computador tem quatro quadros de página. O tempo de carga, o tempo do último acesso e os 
bits R e M de cada página são mostrados a seguir (os tempos estão em tiques de relógio): 
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19. 


20. 


21. 


22. 


23. 


24. 


25. 


26. 


27. 


28. 


Página Carregada Última ref. R M 
0 126 279 0 0 
1 230 260 1 0 
2 120 272 1 1 
3 160 280 1 1 


(a) Qual página o algoritmo NRU substituirá? 
(b) Qual página o algoritmo FIFO substituirá? 
(c) Qual página o algoritmo LRU substituirá? 
(d) Qual página o algoritmo da segunda chance substituirá? 


Se o algoritmo de substituição de página FIFO for usado com quatro quadros de página e oito pági- 
nas, quantas faltas de página ocorrerão com a string de referência 0172327103 se os quatro quadros 
estiverem inicialmente vazios? Agora, repita este problema para o algoritmo LRU. 


Um pequeno computador tem 8 quadros de página, cada um contendo uma página. Os quadros de 
página contêm as páginas virtuais 4, C, G, H, B, L, N, D e F, nessa ordem. Seus respectivos tempos 
de carga foram de 18, 23, 5, 7, 32, 19, 3 e 8. Seus bits de referência são 1, 0, 1, 1, 0, 1, 1 e 0 e seus 
bits modificados são 1, 1, 1, 0, 0, 0, 1 e 1 respectivamente. Qual é a ordem em que o algoritmo da 
segunda chance considera as páginas e qual delas é selecionada? 


Existem quaisquer circunstâncias nas quais o algoritmo do relógio e da segunda chance escolherão 
páginas diferentes para substituir? Se houver, quais são elas? 


Suponha que um computador utilize o algoritmo de substituição de página FFP, mas haja memória 
suficiente para conter todos os processos, sem faltas de página. O que acontece? 


Um pequeno computador tem quatro quadros de página. No primeiro tique de relógio, os bits R 
são 0111 (a página O é O e as restantes são 1). Nos tiques de relógio subseqiientes, os valores são 
1011, 1010, 1101, 0010, 1010, 1100 e 0001. Se o algoritmo do envelhecimento for usado com um 
contador de 8 bits, dê os valores dos quatro contadores após o último tique. 


Quanto tempo demora para carregar um programa de 64 KB de um disco cujo tempo de busca 
médio é de 10 ms, seu tempo de rotação é de 8 ms e suas trilhas contêm 1 MB 


(a) para um tamanho de página de 2 KB? 
(b) para um tamanho de página de 4 KB? 
(c) para um tamanho de página de 64 KB? 


As páginas estão espalhadas aleatoriamente no disco. 


Dados os resultados do problema anterior, por que as páginas são tão pequenas? Cite duas desvan- 
tagens das páginas de 64 KB com relação às páginas de 4 KB. 


Uma das primeiras máquinas de compartilhamento de tempo, o PDP-1, tinha uma memória de 4 K 
palavras de 18 bits. Ele mantinha um processo por vez na memória. Quando o escalonador decidia 
executar outro processo, o que estava na memória era escrito em um tambor de paginação (um tipo 
de disco), com 4K palavras de 18 bits em torno da circunferência do tambor. O tambor podia iniciar 
a escrita (ou leitura) em qualquer palavra, em vez de somente na palavra 0. Por que você acha que 
esse tambor foi escolhido? 


Um sistema embarcado fornece a cada processo 65.536 bytes de espaço de endereçamento, divi- 
didos em páginas de 4096 bytes. Um programa em particular tem um tamanho de texto de 32.768 
bytes, um tamanho de dados de 16.386 bytes e um tamanho de pilha de 15.870 bytes. Esse progra- 
ma caberá no espaço de endereçamento? Se o tamanho de página fosse de 512 bytes, ele caberia? 
Lembre-se de que uma página não pode conter partes de dois segmentos diferentes. 


Foi observado que o número de instruções executadas entre faltas de página é diretamente propor- 
cional ao número de quadros de página alocados para um programa. Se a memória disponível for 
duplicada, o intervalo médio entre faltas de página também é duplicado. Suponha que uma instru- 
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29. 


30. 


31. 


32. 


33. 


34. 


35. 


36. 


37. 


38. 


39. 


ção normal demore 1 microssegundo, mas se ocorre uma falta de página, ele demora 2001 micros- 
segundos (isto é, 2 ms) para tratar do erro. Se um programa demora 60 s para executar, durante os 
quais ocorrem 15.000 erros de página, quanto tempo ele demoraria para ser executado se o dobro 
de memória estivesse disponível? 


Um grupo de projetistas de sistema operacional da Empresa de Computação Frugal está pensan- 
do a respeito de maneiras de reduzir o espaço necessário para seu novo sistema operacional. O 
guru-chefe sugeriu apenas não se incomodar com o salvamento do texto do programa na área de 
swapping, mas apenas paginá-lo diretamente do arquivo binário, quando for necessário. Há algum 
problema nessa estratégia? 


Explique a diferença entre fragmentação interna e fragmentação externa. Qual delas ocorre nos 
sistemas de paginação? Qual delas ocorre nos sistemas que usam segmentação pura? 


Quando estão sendo usadas segmentação e paginação, como no Pentium, primeiro deve ser pes- 
quisado o descritor de segmento e, depois, o descritor de página. O TLB também funciona dessa 
maneira, com dois níveis de pesquisa? 


Por que o esquema de gerenciamento de memória do MINIX 3 torna necessário ter um programa 
como chmem? 


A Figura 4-44 mostra a utilização de memória inicial dos quatro primeiros componentes de um 
sistema MINIX 3. Qual será o valor de cs para o próximo componente carregado após rs? 


Os computadores compatíveis com IBM têm a memória ROM e a memória de dispositivo de E/S 
não disponíveis para uso de programas no intervalo de 640 KB a 1 MB e, depois que o monitor de 
inicialização do MINIX 3 se reposiciona abaixo do limite de 640 KB, a memória disponível para 
uso de programas é ainda mais reduzida. Na Figura 4-44, qual é a quantidade de memória dispo- 
nível para carregar um programa na região entre o núcleo e a região indisponível, se o monitor de 
inicialização tem 52256 bytes alocados para si? 


No problema anterior, importa se o monitor de inicialização ocupa exatamente a quantidade de 
memória que precisa ou se ela é arredondada para unidades de clicks? 


Na Seção 4.7.5, foi mencionado que, em uma chamada de exec, testando a existência de uma lacu- 
na adequada antes de liberar a memória do processo corrente, é obtida uma implementação menos 
que ótima. Refaça esse algoritmo para melhorar isso. 


Na Seção 4.8.4, foi mencionado que seria melhor procurar lacunas para os segmentos de texto e de 
dados separadamente. Implemente esse aprimoramento. 


Reprojete adjust para evitar o problema dos processos que recebem sinais serem eliminados desne- 
cessariamente por causa de um teste de espaço de pilha restrito demais. 


Para identificar a alocação de memória corrente de um processo do MINIX 3, você pode usar o 
comando 


chmem +0 a.out 


mas isso tem o incômodo efeito colateral de reescrever o arquivo e, assim, alterar suas informações 
de data e hora. Modifique o comando chmem para fazer um novo comando showmem, o qual sim- 
plesmente exibe a alocação de memória corrente de seu argumento. 


SISTEMA DE ARQUIVOS 


Todos os aplicativos de computador precisam armazenar e recuperar informações. Enquanto 
um processo está em execução, ele pode armazenar um volume de informações limitado 
dentro de seu próprio espaço de endereçamento. Entretanto, a capacidade de armazenamento 
está restrita ao tamanho do espaço de endereçamento virtual. Para algumas aplicações, esse 
tamanho é adequado, mas para outras, como reservas de passagens aéreas, sistemas bancários 
ou registros coorporativos, ele é pequeno demais. 

Um segundo problema na manutenção de informações dentro do espaço de endereça- 
mento de um processo é que, quando o processo termina, as informações são perdidas. Para 
muitas aplicações, (por exemplo, para bancos de dados), as informações devem ser mantidas 
por semanas, meses ou até para sempre. É inaceitável perdê-las quando o processo que as está 
usando termina. Além disso, elas não devem desaparecer quando uma falha no computador 
elimina o processo. 

Um terceiro problema é que, frequentemente, é necessário vários processos acessarem 
as informações (partes delas) ao mesmo tempo. Por exemplo, se temos um catálogo telefô- 
nico on-line armazenado dentro do espaço de endereçamento de um único processo, apenas 
esse processo pode acessá-lo. A maneira de resolver esse problema é tornar as informações 
em si independentes de qualquer processo. 

Assim, temos três requisitos fundamentais para o armazenamento de informações a 
longo prazo: 


Deve ser possível armazenar um volume muito grande de informações. 
2. As informações devem sobreviver ao término do processo que as estão utilizando. 


3. Vários processos devem ser capazes de acessar as informações concomitante- 
mente. 


A solução usual para todos esses problemas é armazenar as informações em discos e 
outras mídias externas, em unidades chamadas arquivos. Então, os processos podem ler e 
escrever informações novas, se for necessário. As informações armazenadas em arquivos de- 
vem ser persistentes; isto é, não devem ser afetadas pela criação e pelo término do processo. 
Um arquivo só deve desaparecer quando seu criador o remover. 

Os arquivos são gerenciados pelo sistema operacional. O modo como eles são estrutu- 
rados, nomeados, acessados, usados, protegidos e implementados são tópicos importantes no 
projeto do sistema operacional. Como um todo, a parte do sistema operacional que trata com 
arquivos é conhecida como sistema de arquivos e esse é o assunto deste capítulo. 
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5.1 


5.1.1 


Do ponto de vista dos usuários, o aspecto mais importante de um sistema de arquivos 
é como ele aparece para eles; isto é, o que constitui um arquivo, como os arquivos recebem 
seus nomes e como são protegidos, quais operações são permitidas etc. Os detalhes de serem 
utilizadas listas encadeadas ou mapas de bits para monitorar o espaço de armazenamento 
livre e de que existem muitos setores em um bloco lógico têm menos interesse, embora se- 
jam de grande importância para os projetistas do sistema de arquivos. Por isso, estruturamos 
este capítulo com várias seções. As duas primeiras são dedicadas à interface do usuário para 
arquivos e diretórios, respectivamente. Em seguida, há uma discussão sobre maneiras alterna- 
tivas pelas quais um sistema de arquivos pode ser implementado. Após uma discussão sobre 
segurança e mecanismos de proteção, concluímos com uma descrição do sistema de arquivos 
do MINIX 3. 


ARQUIVOS 


Nas páginas a seguir, veremos os arquivos do ponto de vista do usuário; isto é, como eles são 
usados e quais são suas propriedades. 


Atribuição de nomes de arquivo 


Os arquivos são um mecanismo de abstração. Eles proporcionam uma maneira de armazenar 
informações no disco e de lê-las posteriormente. Isso deve ser feito de modo a esconder do 
usuário os detalhes sobre como e onde as informações são armazenadas e como os discos 
realmente funcionam. 

Provavelmente, a característica mais importante de qualquer mecanismo de abstração é 
a maneira de atribuir nomes aos objetos que estão sendo gerenciados; portanto, começaremos 
nosso estudo dos sistemas de arquivos com o assunto da atribuição de nomes de arquivo. 
Quando um processo cria um arquivo, é dado um nome a ele. Quando o processo termina, o 
arquivo continua a existir e pode ser acessado por outros processos, usando seu nome. 

As regras de atribuição de nomes de arquivo exatas variam de um sistema para outro, 
mas todos os sistemas operacionais atuais permitem strings de uma a oito letras como nomes 
de arquivo válidos. Assim, andrea, bruce e cathy são possíveis nomes de arquivo. Freqiiente- 
mente, algarismos e caracteres especiais também são permitidos; assim, nomes como 2, ur- 
gente! e Fig.2-14 frequentemente também são válidos. Muitos sistemas de arquivos suportam 
nomes de até 255 caracteres. 

Alguns sistemas de arquivos fazem distinção entre letras maiúsculas e minúsculas, en- 
quanto outros, não. O UNIX (incluindo todas as suas variantes) entra na primeira categoria; 
o MS-DOS, na segunda. Assim, um sistema UNIX pode ter todos os seguintes nomes como 
três arquivos distintos: maria, Maria e MARIA. No MS-DOS, todos esses nomes referem-se 
ao mesmo arquivo. 

O Windows fica entre esses extremos. Os sistemas de arquivos do Windows 95 e Win- 
dows 98 são baseados no sistema de arquivos do MS-DOS e, assim, herdam muitas de suas 
propriedades, como o modo de construir nomes de arquivo. A cada nova versão foram adicio- 
nados aprimoramentos, mas os recursos que discutiremos são comuns no MS-DOS de modo 
geral e nas versões clássicas do Windows. Além disso, o Windows NT, o Windows 2000 e o 
Windows XP suportam o sistema de arquivos do MS-DOS. Entretanto, estes últimos sistemas 
também têm um sistema de arquivos nativo (o NTFS), que tem propriedades diferentes (como 
nomes de arquivo em Unicode). Esse sistema de arquivos também passou por alterações nas 
sucessivas versões. Neste capítulo, vamos nos referir aos sistemas mais antigos como sistema 
de arquivos do Windows 98. Se um recurso não se aplicar às versões do MS-DOS ou do Win- 
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dows 95, indicaremos isso. Do mesmo modo, vamos nos referir ao sistema mais recente como 
sistema de arquivos NTFS ou como sistema de arquivos do Windows XP e destacaremos isso, 
caso um aspecto que esteja sendo discutido também não se aplique aos sistemas de arquivos 
do Windows NT ou do Windows 2000. Quando dissermos apenas Windows, isso significará 
todos os sistemas de arquivos do Windows, desde o Windows 95. 

Muitos sistemas operacionais suportam nomes de arquivo com duas partes, sendo elas 
separadas por um ponto, como em prog.c. A parte após o ponto é chamada de extensão de 
arquivo e normalmente indica algo a respeito do arquivo (neste exemplo, que se trata de um 
arquivo-fonte da linguagem de programação C. No MS-DOS, por exemplo, os nomes de 
arquivo têm de 1 a 8 caracteres, mais uma extensão opcional de 1 a 3 caracteres. No UNIX, 
o tamanho da extensão, se houver, fica por conta do usuário, e um arquivo pode até ter duas 
ou mais extensões, como em prog.c.bz2, onde .bz2 é comumente usado para indicar que o 
arquivo (prog.c) foi compactado usando o algoritmo de compactação bzip2. Algumas das 
extensões de arquivo mais comuns e seus significados aparecem na Figura 5-1. 


Extensão Significado 

arquivo.bak Arquivo de backup 
arquivo.c Programa fonte em C 
arquivo.gif Imagem no formato Graphical Interchange Format 
arquivo.html Documento em HyperText Markup Language da World Wide Web 
arquivo.iso Imagem ISO de um CD-ROM (para gravar no CD) 
arquivo.jpg Fotografia codificada com o padrão JPEG 
arquivo.mp3 | Música codificada no formato de áudio MPEG camada 3 
arquivo.mpg Filme codificado com o padrão MPEG 
arquivo.o Arquivo-objeto (saída do compilador ainda não vinculada) 
arquivo.pdf Arquivo no formato Portable Document Format 
arquivo.ps Arquivo em PostScript 
arquivo.tex Entrada para o programa de formatação TEX 
arquivo.txt Arquivo de texto geral 
arquivo.zip Repositório de arquivos compactado 

Figura 5-1 Algumas extensões de arquivo típicas. 


Em alguns sistemas (por exemplo, o UNIX), as extensões de arquivo são apenas conven- 
ções e não são impostas pelo sistema operacional. Um arquivo chamado arquivo.txt poderia 
ser algum tipo de arquivo de texto, mas esse nome serve mais para lembrar o proprietário do 
que para transmitir qualquer informação para o computador. Por outro lado, um compilador 
C pode fazer questão de que os arquivos a serem compilados terminem com .c e se recusar a 
compilá-los, caso não terminem. 

Convenções como essas são particularmente úteis quando o mesmo programa pode ma- 
nipular vários tipos diferentes de arquivos. O compilador C, por exemplo, pode receber uma 
lista de arquivos para compilar e ligar, alguns deles sendo arquivos em C (por exemplo, foo. 
c), alguns em linguagem assembly (por exemplo, bars) e alguns sendo arquivos-objeto (por 
exemplo, other.o). Então, a extensão torna-se fundamental para o compilador identificar quais 
são os arquivos em C, quais são arquivos em assembly e quais são arquivos-objeto. 
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5.1.2 


(a) 


Em contraste, o Windows é muito atento quanto às extensões e atribui significado para 
elas. Os usuários (ou processos) podem registrar extensões no sistema operacional e especi- 
ficar qual programa esta associado a cada uma delas. Quando um usuário dá um duplo clique 
em um nome de arquivo, o programa atribuído a sua extensão de arquivo é ativado e recebe o 
nome do arquivo como parâmetro. Por exemplo, dar um duplo clique em arquivo.doc inicia o 
programa Word da Microsoft, com arquivo.doc sendo o arquivo inicial a ser editado. 

Pode-se achar estranho a Microsoft ter optado por tornar as extensões comuns invisíveis 
por padrão, devido a sua importância. Felizmente, a maioria das configurações “erradas por 
padrão” do Windows pode ser alterada por um usuário sofisticado que saiba onde procurar. 


Estrutura do arquivo 


Os arquivos podem ser estruturados de várias maneiras. Três possibilidades comuns aparecem 
na Figura 5-2. O arquivo da Figura 5-2(a) é apenas uma sequência não estruturada de bytes. 
Na verdade, o sistema operacional não sabe ou não se preocupa com o que há no arquivo. 
Tudo que ele vê são bytes. Qualquer significado deve ser imposto pelos programas em nível 
de usuário. Tanto o UNIX como o Windows 98 usam essa estratégia. 

O fato de o sistema operacional enxergar os arquivos como nada mais do que sequên- 
cias de bytes proporciona o máximo de flexibilidade. Os programas de usuário podem colocar 
o que quiserem em seus arquivos e chamá-los da maneira que for conveniente. O sistema 
operacional não ajuda, mas também não atrapalha. Para usuários que queiram fazer coisas 
incomuns, este último aspecto pode ser muito importante. 


1 Byte 1 Registro 


Fred [ro] 


aoaaa 


(b) (c) 


Figura 5-2 Três tipos de arquivos. (a) Seqüência de bytes. (b) Seqüência de registros. (c) Árvore. 


A primeira etapa na estrutura aparece na Figura 5-2(b). Nesse modelo, um arquivo é 
uma seqiiência de registros de tamanho fixo, cada um com alguma estrutura interna. O mais 
importante na idéia de um arquivo ser uma segiiência de registros é a noção de que a operação 
de leitura retorna apenas um registro e a operação de escrita sobrescreve ou anexa apenas um 
registro. Como um dado histórico, quando o cartão perfurado de 80 colunas reinava, os sis- 
temas operacionais (de computadores de grande porte) baseavam seus sistemas de arquivos 
em arquivos compostos de registros de 80 caracteres, na verdade, imagens de cartão. Esses 
sistemas também suportavam arquivos de registros de 132 caracteres, os quais se destinavam 
à impressora de linha (as quais, naquela época, eram impressoras enormes com 132 colunas). 
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5.1.3 


Os programas liam a entrada em unidades de 80 caracteres e escreviam em unidades de 132 
caracteres, embora os últimos 52 pudessem ser espaços, naturalmente. Nenhum sistema de 
propósito geral atual funciona assim. 

O terceiro tipo de estrutura de arquivo aparece na Figura 5-2(c). Nessa organização, um 
arquivo consiste em uma árvore de registros, não necessariamente todos do mesmo tamanho, 
mas cada um contendo um campo de chave em uma posição fixa no registro. A árvore é orde- 
nada pelo campo de chave, permitindo localizar rapidamente uma chave em particular. 

A operação básica aqui não é obter o “próximo” registro, embora isso também seja 
possível, mas obter o registro com uma chave específica. Para o arquivo zoo da Figura 5-2(c), 
poderia ser solicitado que o sistema obtivesse o registro cuja chave é pônei, por exemplo, 
sem se preocupar com sua posição exata no arquivo. Além disso, novos registros podem ser 
adicionados no arquivo, com o sistema operacional (e não o usuário) decidindo onde colocá- 
los. Esse tipo de arquivo é claramente muito diferente dos fluxos de bytes não estruturados 
utilizados no UNIX e no Windows 98, mas é amplamente usado nos computadores de grande 
porte ainda utilizados no processamento de dados comerciais. 


Tipos de arquivo 


Muitos sistemas operacionais suportam vários tipos de arquivos. O UNIX e o Windows, por 
exemplo, têm arquivos normais e diretórios. O UNIX tem também arquivos especiais de carac- 
tere e de bloco. O Windows XP também usa arquivos de metadados, os quais mencionaremos 
posteriormente. Os arquivos normais são aqueles que contêm informações do usuário. Todos 
os arquivos da Figura 5-2 são normais. Os diretórios são arquivos de sistema para manter a 
estrutura do sistema de arquivos. Estudaremos os diretórios a seguir. Os arquivos especiais de 
caractere são relacionados à entrada/saída e usados para modelar dispositivos de E/S seriais, 
como terminais, impressoras e redes. Os arquivos especiais de bloco são usados para modelar 
discos. Neste capítulo, estaremos interessados principalmente nos arquivos normais. 

Os arquivos normais geralmente são arquivos ASCII ou arquivos binários. Os arquivos 
ASCII consistem em linhas de texto. Em alguns sistemas, cada linha termina com um caractere 
de carriage return. Em outros, é usado o caractere de avanço de linha (line feed). Alguns siste- 
mas usam ambos (por exemplo, o Windows). As linhas não precisam ter todas a mesma largura. 

A grande vantagem dos arquivos ASCII é que eles podem ser exibidos e impressos no 
estado em que se encontram e podem ser editados com qualquer editor de textos. Além disso, 
se um grande número de programas utiliza arquivos ASCII para entrada e saída, é fácil conec- 
tar a saída de um programa na entrada de outro, como ocorre no caso de pipes em um shell. 
(comunicar processos não é nada fácil, mas interpretar as informações certamente é, caso 
uma convenção padrão, como o ASCII, for usado para expressá-las.) 

Outros arquivos são binários, o que significa apenas que não são arquivos ASCII. Impri- 
mi-los resulta em uma listagem incompreensível, repleta do que aparentemente é apenas lixo. 
Normalmente, eles têm alguma estrutura interna, conhecida dos programas que os utilizam. 

Por exemplo, na Figura 5-3(a), vemos um arquivo binário executável simples, obtido de 
uma versão UNIX mais antiga. Embora, tecnicamente, o arquivo seja apenas uma sequência 
de bytes, o sistema operacional só executará um arquivo se ele tiver o formato correto. Ele 
tem cinco seções: cabeçalho, texto, dados, bits de realocação e tabela de símbolos. O cabeça- 
lho começa com o chamado número mágico, identificando o arquivo como executável (para 
impedir a execução acidental de um arquivo que não esteja nesse formato). Em seguida, vêm 
os tamanhos das várias partes do arquivo, o endereço no qual a execução começa e alguns bits 
de flag. Após o cabeçalho estão o texto e os dados do programa em si. Eles são carregados 
na memória e os endereços corrigidos usando os bits de realocação. A tabela de símbolos é 
usada para depuração. 
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Nosso segundo exemplo de arquivo binário é um repositório de arquivos, também do 
UNIX. Ele consiste em um conjunto de funções de biblioteca (módulos) compiladas, mas não 
ligadas. Cada uma tem como prefácio um cabeçalho indicando seu nome, data da criação, 
proprietário, código de proteção e tamanho. Exatamente como acontece com o arquivo exe- 
cutável, os cabeçalhos do módulo estão repletos de números binários. Copiá-los na impresso- 
ra produziria simplesmente lixo. 

Todo sistema operacional deve reconhecer pelo menos um tipo de arquivo — seu próprio 
arquivo executável —, mas alguns sistemas operacionais reconhecem mais. O antigo sistema 
TOPS-20 (da DECsystem 20) ia a ponto de examinar a hora da criação de qualquer arquivo a 
ser executado. Então, localizava o arquivo-fonte e via se o código-fonte tinha sido modificado 
desde a criação do binário. Se tivesse sido, recompilava o código-fonte automaticamente. Em 
termos de UNIX, o programa make foi incorporado ao shell. As extensões de arquivo eram 
obrigatórias, de modo que o sistema operacional podia identificar qual programa binário era 
derivado de qual código-fonte. 


Cabeçalho 


Tamanho da 
tabela de símbolos 


Cabeçalho 


Cabeçalho Ro 


Ponto de entrada 


Módulo 
objeto 
D 


| adós | Cabeçalho 
Bits de 


realocação 


Módulo 
objeto 
Tabela de 
| símbolos | 


(a) (b) 


Figura 5-3 (a) Um arquivo executável. (b) Um repositório de arquivos. 


Ter arquivos fortemente tipados como esse causa problemas quando o usuário faz algo 
que os projetistas do sistema não esperavam. Considere, como exemplo, um sistema no qual 
os arquivos de saída do programa têm extensão .dat (arquivos de dados). Se um usuário 
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5.1.4 


5.1.5 


escrever um formatador de programa que leia um arquivo .c (programa em C), o transforme 
(por exemplo, convertendo-o para um layout de alinhamento padrão) e depois escreva o 
arquivo transformado como saída, o arquivo de saída será de tipo .dat. Se o usuário tentar 
compilá-lo, o sistema se recusará, pois ele tem a extensão errada. As tentativas de copiar 
arquivo.dat em arquivo.c serão rejeitadas pelo sistema como inválidas (para proteger o 
usuário contra erros). 

Embora esse tipo de “camaradagem com o usuário” possa ajudar os iniciantes, deixa 
os usuários experientes desesperados, pois precisam dedicar um esforço considerável para 
contornar a idéia que o sistema operacional tem sobre o que é razoável e o que não é. 


Acesso a arquivo 


Os sistemas operacionais antigos forneciam apenas um tipo de acesso a arquivo: o acesso se- 
qiiencial. Nesses sistemas, um processo podia ler todos os bytes ou registros em um arquivo 
na ordem, começando no princípio, mas não podia pular e lê-los fora de ordem. Entretanto, 
era possível voltar ao início do arquivo, de modo que eles podiam ser lidos quantas vezes 
fossem necessárias. Os arquivos sequenciais eram convenientes quando o meio de armazena- 
mento era uma fita magnética, em vez de disco. 

Quando os discos começaram a ser usados para armazenar arquivos, tornou-se possível 
ler os bytes ou registros de um arquivo fora de ordem ou acessar registros pela chave, em vez 
de ler pela posição. Os arquivos cujos bytes ou registros podem ser lidos em qualquer ordem 
são chamados de arquivos de acesso aleatório. Eles são exigidos por muitos aplicativos. 

Os arquivos de acesso aleatório são fundamentais para muitos aplicativos, como por 
exemplo, os sistemas de banco de dados. Se um cliente de uma companhia aérea telefonar e 
quiser reservar um assento em determinado vôo, o programa de reservas deve ser capaz de 
acessar o registro desse vôo sem ter de ler primeiro os registros de milhares de outros vôos. 

Dois métodos são usados para especificar onde a leitura vai começar. No primeiro, cada 
operação read fornece a posição no arquivo na qual a leitura deve começar. No segundo, uma 
operação especial, seek, é fornecida para estabelecer a posição corrente. Após uma operação 
seek, o arquivo pode ser lido segiiencialmente a partir da posição corrente atual. 

Em alguns sistemas operacionais de computadores de grande porte mais antigos, os 
arquivos são classificados como sendo de acesso seqüencial ou aleatório no momento em que 
são criados. Isso possibilita que o sistema utilize diferentes técnicas de armazenamento para 
as duas classes. Os sistemas operacionais modernos não fazem essa distinção. Todos os seus 
arquivos são automaticamente de acesso aleatório. 


Atributos de arquivo 


Todo arquivo tem um nome e dados. Além disso, todos os sistemas operacionais associam 
outras informações a cada arquivo, por exemplo, a data e hora em que o arquivo foi criado 
e o tamanho do arquivo. Chamaremos esses itens extras de atributos do arquivo, embora 
algumas pessoas os chamem de metadados. A lista de atributos varia consideravelmente de 
um sistema para outro. A tabela da Figura 5-4 mostra algumas das possibilidades, mas tam- 
bém existem outras. Nenhum sistema tem todas elas, mas cada uma está presente em algum 
sistema. 

Os quatro primeiros atributos se relacionam com a proteção do arquivo e informam 
quem pode acessá-lo e quem não pode. Todos os tipos de esquemas são possíveis, alguns dos 
quais estudaremos posteriormente. Em alguns sistemas, o usuário precisa apresentar uma 
senha para acessar um arquivo, no caso em que a senha deve ser um dos atributos. 
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Atributo Significado 
Proteção Quem pode acessar o arquivo e de que maneira 
Senha A senha necessária para acessar o arquivo 
Criador ID da pessoa que criou o arquivo 
Proprietário Proprietário atual 
Flag de leitura somente O para leitura/escrita; 1 para leitura somente 
Flag de oculto O para normal; 1 para não exibir em listagens 
Flag de sistema O para arquivos normais; 1 para arquivo de sistema 
Flag de arquivamento O para salvo em backup; 1 para ser salvo em backup 
Flag de ASCll/binário O para arquivo ASCII; 1 para arquivo binário 
Flag de acesso aleatório O para acesso sequencial somente; 1 para acesso aleatório 
Flag de temporário O para normal; 1 para excluir arquivo na saída do processo 
Flags de travamento O para destravado; diferente de zero para travado 
Tamanho do registro Número de bytes em um registro 
Posição da chave Deslocamento da chave dentro de cada registro 
Tamanhos da chave Número de bytes no campo de chave 
Tempo da criação Data e hora em que o arquivo foi criado 


Tempo do último acesso Data e hora em que o arquivo foi acessado pela última vez 


Tempo da última alteração | Data e hora em que o arquivo foi alterado pela última vez 


Tamanho corrente Número de bytes no arquivo 


Tamanho máximo Número de bytes até o qual o arquivo pode crescer 


Figura 5-4 Alguns atributos de arquivo possíveis. 


Os flags são bits, ou campos simples, que controlam ou ativam alguma propriedade 
específica. Os arquivos ocultos, por exemplo, não aparecem nas listagens dos arquivos. O 
flag de arquivamento é um bit que monitora se foi feito o backup do arquivo. O programa de 
backup desativa o bit e o sistema operacional o ativa quando um arquivo é alterado. Desse 
modo, o programa de backup pode identificar quais arquivos precisam de backup. O flag de 
temporário permite que um arquivo seja marcado para exclusão automática, quando o proces- 
so que o criou terminar. 

Os campos de tamanho do registro, posição da chave e tamanho da chave só estão pre- 
sentes em arquivos cujos registros podem ser pesquisados usando uma chave. Eles fornecem 
as informações exigidas para encontrar as chaves. 

Os vários tempos monitoram quando o arquivo foi criado, acessado mais recentemente 
e o modificado. Eles são úteis para uma variedade de propósitos. Por exemplo, um arquivo- 
fonte que foi modificado após a criação do arquivo-objeto correspondente precisa ser recom- 
pilado. Esses campos fornecem as informações necessárias. 

O tamanho corrente informa o tamanho atual do arquivo. Alguns sistemas operacionais 
de computadores de grande porte antigos exigem que o tamanho máximo seja especificado 
quando o arquivo é criado, para permitir que o sistema operacional reserve a máxima quanti- 
dade de armazenamento antecipadamente. Os sistemas operacionais modernos são inteligen- 
tes o suficiente para prescindirem desse recurso. 
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5.1.6 Operações sobre arquivos 


Os arquivos existem para armazenar informações e permitir que elas sejam recuperadas pos- 
teriormente. Diferentes sistemas fornecem diferentes operações para permitir o armazena- 
mento e a recuperação. A seguir está uma discussão sobre as chamadas de sistema mais co- 
muns relacionadas aos arquivos. 


1. 


10. 


Create. O arquivo é criado sem dados. O objetivo da chamada é anunciar que o 
arquivo está sendo criado e configurar alguns atributos. 


Delete. Quando o arquivo não é mais necessário, precisa ser excluído para liberar 
espaço em disco. Sempre é fornecida uma chamada de sistema para esse propósito. 


Open. Antes de usar um arquivo, um processo precisa abri-lo. O objetivo da cha- 
mada de open é permitir que o sistema busque os atributos e a lista de endereços de 
disco na memória principal, para acesso rápido nas chamadas posteriores. 


Close. Quando todos os acessos tiverem terminado, os atributos e os endereços de 
disco não serão mais necessários; portanto, o arquivo deve ser fechado para liberar 
espaço em tabelas internas do sistema operacional. Muitos sistemas estimulam 
isso, impondo um número máximo de arquivos abertos nos processos. Um disco é 
escrito em blocos e o fechamento de um arquivo obriga a escrita do último bloco 
do arquivo, mesmo que esse bloco possa ainda não estar totalmente cheio. 


Read. Os dados são lidos do arquivo. Normalmente, os bytes são provenientes da 
posição corrente. O processo que fez a chamada deve especificar quantos dados 
são necessários e também fornecer um buffer para colocá-los. 


Write. Os dados são escritos no arquivo, em geral, novamente, na posição corren- 
te. Se a posição corrente for o final do arquivo, o tamanho do arquivo aumentará. 
Se a posição corrente for no meio do arquivo, os dados existentes serão sobrescri- 
tos e perdidos para sempre. 


Append. Esta chamada é uma forma restrita de write. Ela só pode adicionar dados 
no final do arquivo. Os sistemas que fornecem um conjunto mínimo de chamadas 
de sistema geralmente não têm a operação append, mas muitos sistemas fornecem 
várias maneiras de fazer a mesma coisa e, às vezes, esses sistemas têm a operação 
append. 


Seek. Para arquivos de acesso aleatório, é necessário um método para especifi- 
car de onde os dados serão extraídos. Uma estratégia comum é uma chamada de 
sistema, seek, que reposiciona o ponteiro de arquivo para um local específico no 
arquivo. Depois que essa chamada termina, os dados podem ser lidos ou escritos 
nessa posição. 

Get attributes. Freqüentemente, os processos precisam ler atributos de arquivo 
para fazer seu trabalho. Por exemplo, o programa make do UNIX é usado normal- 
mente para gerenciar projetos de desenvolvimento de software compostos de mui- 
tos arquivos-fonte. Quando o programa make é chamado, ele examina os tempos 
de modificação de todos os arquivos-fonte e arquivos-objeto, e faz as compilações 
necessárias para que tudo esteja atualizado. Para realizar seu trabalho, make preci- 
sa ler os atributos, a saber, os tempos de modificação. 


Set attributes. Alguns atributos são configurados pelo usuário e podem ser altera- 
dos depois que o arquivo foi criado. Esta chamada de sistema torna isso possível. 
As informações de modo de proteção são um exemplo óbvio. A maioria dos flags 
também entra nesta categoria. 
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11. Rename. Fregiientemente acontece de um usuário precisar alterar o nome de um 
arquivo já existente. Esta chamada de sistema torna isso possível. Ela nem sempre 
é rigorosamente necessária, pois o arquivo normalmente pode ser copiado em um 
novo arquivo com o novo nome e, então, o arquivo antigo pode ser excluído. 


12. Lock. Travar um arquivo ou uma parte de um arquivo impede a existência de vá- 
rios acessos simultâneos por diferentes processos. Para um sistema de reservas 
de passagens aéreas, por exemplo, travar o banco de dados enquanto se faz uma 
reserva evita a marcação de um assento para dois passageiros diferentes. 


5.2 DIRETÓRIOS 


5.2.1 


Para monitorar os arquivos, os sistemas de arquivos normalmente têm diretórios ou pastas, 
os quais, em muitos sistemas, também são arquivos. Nesta seção, discutiremos os diretórios, 
sua organização, suas propriedades e as operações que podem ser efetuadas neles. 


Diretórios simples 

Normalmente, um diretório contém várias entradas, uma por arquivo. Uma possibilidade apa- 
rece na Figura 5-5(a), na qual cada entrada contém o nome do arquivo, os atributos do arquivo 
e os endereços de disco onde os dados estão armazenados. Outra possibilidade aparece na 
Figura 5-5(b). Aqui, uma entrada de diretório contém o nome do arquivo e um ponteiro para 
outra estrutura de dados onde são encontrados os atributos e os endereços de disco. Esses dois 
sistemas são comumente usados. 

Quando um arquivo é aberto, o sistema operacional pesquisa seu diretório até encontrar 
o nome do arquivo a ser aberto. Então, ele extrai os atributos e endereços de disco, ou direta- 
mente a partir da entrada de diretório ou da estrutura de dados apontada, e os coloca em uma 
tabela na memória principal. Todas as referências subsegiientes ao arquivo usam as informa- 
ções que estão na memória principal. 

O número de diretórios varia de um sistema para outro. A forma mais simples de siste- 
ma de diretório é um único diretório contendo todos os arquivos de todos os usuários, como 
ilustrado na Figura 5-6(a). Nos primeiros computadores pessoais, esse sistema de diretório 
único era comum, em parte porque havia apenas um usuário. 


LI] 
sie 
LI] 


trabalho | 


(a) (b) Estrutura de 
iis dados contendo 
os atributos 


Figura 5-5 (a) Atributos na própria entrada de diretório. (b) Atributos em outro lugar. 


O problema de ter apenas um diretório em um sistema com vários usuários é que dife- 
rentes usuários podem, acidentalmente, usar os mesmos nomes para seus arquivos. Por exem- 
plo, se o usuário A cria um arquivo chamado mailbox e, posteriormente, o usuário B também 
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cria um arquivo chamado mailbox, o arquivo de B sobrescreverá o arquivo de A. Consegiien- 
temente, esse esquema não é mais usado em sistemas multiusuário, mas poderia ser usado em 
um pequeno sistema embarcado, por exemplo, um assistente digital pessoal portátil (PDA) 
ou um telefone celular. 

Para evitar os conflitos causados pelo fato de diferentes usuários escolherem o mesmo 
nome de arquivo para seus próprios arquivos, o próximo passo é fornecer a cada usuário 
um diretório privado. Desse modo, os nomes escolhidos por um usuário não interferem 
nos nomes escolhidos por outro, e não há nenhum problema causado pelo fato de o mesmo 
nome ocorrer em dois ou mais diretórios. Esse projeto leva ao sistema da Figura 5-6(b). 
Ele poderia ser usado, por exemplo, em um computador multiusuário ou em uma rede de 
computadores pessoais simples que compartilhasse um servidor de arquivos comum em uma 
rede local. 

Implícito nesse projeto está o fato de que, quando um usuário tenta abrir um arquivo, 
o sistema operacional sabe quem é ele, para saber qual diretório deve pesquisar. Como con- 
sequência, é necessário algum tipo de procedimento de login, no qual o usuário especifique 
um nome de login ou uma identificação, algo não exigido em um sistema de diretório de um 
único nível. 

Quando esse sistema é implementado em sua forma mais básica, os usuários só podem 
acessar arquivos em seus próprios diretórios. 


5.2.2 Sistemas de diretório hierárquicos 


A hierarquia de dois níveis elimina os conflitos de nome de arquivo entre os usuários. Mas 
outro problema é que os usuários com muitos arquivos talvez queiram agrupá-los em sub- 
grupos menores; por exemplo, um professor talvez queira separar anotações para uma aula a 
partir de rascunhos de capítulos de um novo livro-texto. O que é necessário é uma hierarquia 
geral (isto é, uma árvore de diretórios). Com essa estratégia, cada usuário pode ter quantos 
diretórios forem necessários para que os arquivos possam ser agrupados naturalmente. Essa 
estratégia aparece na Figura 5-6(c). Aqui, os diretórios A, B e C contidos no diretório-raiz 
pertencem cada um a um usuário diferente, dois dos quais criaram subdiretórios para projetos 
em que estão trabalhando. 


| Diretório-raiz 


Ca) (a) (B) TO) 


(a) (b) (c) 


Figura 5-6 Três projetos de sistema de arquivos. (a) Diretório único compartilhado por todos os usuá- 
rios. (b) Um diretório por usuário. (c) Arvore arbitrária por usuário. As letras indicam o proprietário do 
diretório ou arquivo. 
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5.2.3 


A capacidade de criar um número arbitrário de subdiretórios fornece uma ferramenta 
de estruturação poderosa para os usuários organizarem seu trabalho. Por isso, praticamente 
todos os sistemas de arquivos de PCs e servidores modernos são organizados dessa maneira. 

Entretanto, conforme mencionamos antes, a história frequentemente se repete com no- 
vas tecnologias. As câmaras digitais precisam registrar suas imagens em algum lugar, nor- 
malmente em uma memória flash. As primeiras câmaras digitais tinham um único diretório e 
chamavam os arquivos de DSC0001.JPG, DSC0002.JPG etc. Entretanto, não demorou muito 
para os fabricantes de câmaras construírem sistemas de arquivos com vários diretórios, como 
se vê na Figura 5-6(b). Que diferença faz se nenhum dos proprietários de câmara sabe usar 
vários diretórios e, provavelmente, não poderiam imaginar qualquer uso para esse recurso, 
mesmo que soubessem? Afinal, isso é apenas software (incorporado) e, assim, não custa qua- 
se nada para o fabricante fornecer. Será que vai demorar muito para surgirem câmaras digitais 
com sistemas de arquivos hierárquicos completos, múltiplos logins e nomes de arquivo de 
255 caracteres? 


Nomes de caminho 


Quando o sistema de arquivos é organizado como uma árvore de diretórios, é necessário al- 
guma maneira de especificar os nomes de arquivo. Dois métodos diferentes são comumente 
usados. No primeiro método, cada arquivo recebe um nome de caminho absoluto (absolute 
path name), consistindo no caminho do diretório-raiz até o arquivo. Como exemplo, o cami- 
nho /usr/ast/mailbox significa que o diretório-raiz contém um subdiretório usr/ que, por sua 
vez, contém um subdiretório ast/, o qual contém o arquivo mailbox. Os nomes de caminho 
absolutos sempre começam no diretório-raiz e são exclusivos. No UNIX, os componentes do 
caminho são separados por /. No Windows, o separador é 1. Assim, nesses dois sistemas, o 
mesmo nome de caminho seria escrito como segue: 


Windows \usr\ast\mailbox 
UNIX /usr/ast/mailbox 


Independente do caractere usado, se o primeiro caractere do nome de caminho é o separador, 
então o caminho é absoluto. 

O outro tipo de nome é o nome de caminho relativo (relative path name). Ele é usado 
em conjunto com o conceito de diretório de trabalho (working directory), também chamado 
de diretório corrente (current directory). Um usuário pode designar um diretório como dire- 
tório de trabalho corrente, no caso em que todos os nomes de caminho que não começam no 
diretório-raiz são considerados relativos ao diretório de trabalho. Por exemplo, se o diretório 
de trabalho corrente é /usr/ast, então o arquivo cujo caminho absoluto é /usr/ast/mailbox 
pode ser referenciado simplesmente como mailbox. Em outras palavras, o comando UNIX 


cp /usr/ast/mailbox /usr/ast/mailbox.bak 
e o comando 
cp mailbox mailbox.bak 


fazem exatamente a mesma coisa, se o diretório de trabalho é /usr/ast/. Frequentemente, a 
forma relativa é mais conveniente, mas faz a mesma coisa que a forma absoluta. 

Alguns programas precisam acessar um arquivo específico sem considerar qual é o 
diretório de trabalho. Nesse caso, eles sempre devem usar nomes de caminho absolutos. Por 
exemplo, um corretor ortográfico talvez precise ler /usr/lib/dictionary para fazer seu trabalho. 
Nesse caso, ele deve usar o nome de caminho absoluto completo, pois não sabe qual será o 
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diretório de trabalho quando for chamado. O nome de caminho absoluto sempre funciona, 
independente de qual seja o diretório de trabalho. 

É claro que, se o corretor ortográfico precisar de um grande número de arquivos de 
/usr/lib/, uma estratégia alternativa será executar uma chamada de sistema para mudar seu 
diretório de trabalho para /usr/lib/ e, então, usar apenas dictionary como primeiro parâmetro 
de open. Mudando o diretório de trabalho explicitamente, ele sabe com certeza onde está na 
árvore de diretórios, de modo que, então, pode usar caminhos relativos. 

Cada processo tem seu próprio diretório de trabalho; portanto, quando um processo 
muda seu diretório de trabalho e depois sai, nenhum outro processo é afetado e não resta 
nenhum vestígio da mudança no sistema de arquivos. Dessa maneira, é sempre perfeitamente 
seguro um processo alterar seu diretório de trabalho quando for conveniente. Por outro lado, 
se uma função de biblioteca mudar o diretório de trabalho e não voltar para onde estava ao 
terminar, o restante do programa poderá não funcionar, porque sua suposição sobre onde está 
pode agora ser repentinamente inválida. Por isso, as funções de biblioteca raramente mudam 
o diretório de trabalho e quando precisam fazer isso, elas sempre voltam ao inicial, antes de 
retornar. 

A maioria dos sistemas operacionais que suportam um sistema de diretório hierárqui- 
co tem duas entradas especiais em cada diretório, “” e “.”, geralmente pronunciadas como 
“ponto” e “ponto-ponto”. O ponto refere-se ao diretório corrente; ponto-ponto refere-se ao 
seu pai. Para ver como eles são usados, considere a árvore de arquivos UNIX da Figura 5-7. 
Certo processo tem /usr/ast/ como diretório de trabalho. Ele pode usar.. para subir na árvore. 


Diretório-raiz 


bin tmp 


=— /usr/jim 


Figura 5-7 Uma árvore de diretórios UNIX. 
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Por exemplo, ele pode copiar o arquivo /usr/lib/dictionary em seu próprio diretório, usando 
o comando 


cp ../lib/dictionary . 


O primeiro caminho instrui o sistema a ir para cima (para o diretório usr) e, depois, para ir 
para baixo até o diretório lib/, para encontrar o arquivo dictionary. 

O segundo argumento (o ponto) fornece o nome do diretório corrente. Quando o co- 
mando cp recebe um nome de diretório (incluindo o ponto) como último argumento, ele copia 
todos os arquivos lá. É claro que uma maneira mais normal de fazer a cópia seria digitar 


cp /usr/lib/dictionary . 

Aqui, o uso do ponto evita que o usuário digite dictionary uma segunda vez. Contudo, digitar 
cp /usr/lib/dictionary dictionary 

também funciona bem, assim como 
cp /usr/lib/dictionary /usr/ast/dictionary 


Todos esses comandos fazem exatamente a mesma coisa. 


Operações sobre diretórios 


As chamadas de sistema para gerenciamento de diretórios apresentam mais variações de um 
sistema para outro do que as chamadas de sistema para arquivos. Para dar uma idéia do que 
são e de como funcionam, daremos um exemplo (tirado do UNIX). 


1. Create. Um diretório é criado. Ele está vazio, exceto pelo ponto e pelo ponto-pon- 
to, que são colocados lá automaticamente pelo sistema (ou, em alguns casos, pelo 
programa mkdir). 


2. Delete. Um diretório é excluído. Somente um diretório vazio pode ser excluído. 
Um diretório contendo apenas ponto e ponto-ponto é considerado vazio, pois eles 
normalmente não podem ser excluídos. 


3. Opendir. Os diretórios podem ser lidos. Por exemplo, para listar todos os arquivos 
em um diretório, um programa de listagem abre o diretório para ler os nomes de 
todos os arquivos que ele contém. Antes que um diretório possa ser lido, ele deve 
ser aberto, o que é análogo a abrir e ler um arquivo. 


4. Closedir. Quando um diretório foi lido, ele deve ser fechado para liberar espaço 
em tabelas internas do sistema operacional. 


5. Readdir. Esta chamada retorna a próxima entrada em um diretório aberto. Antiga- 
mente, era possível ler diretórios usando a chamada de sistema read normal, mas 
essa estratégia tem a desvantagem de obrigar o programador a conhecer e a lidar 
com a estrutura interna dos diretórios. Em contraste, readdir sempre retorna uma 
entrada em um formato padrão, independente de qual das possíveis estruturas de 
diretório esteja sendo usada. 


6. Rename. Sob muitos aspectos, os diretórios são exatamente como os arquivos e 
podem ser renomeados da mesma maneira que os arquivos. 


7. Link. A vinculação, ou atalhos, é uma técnica que permite a um arquivo aparecer 
em mais de um diretório. Esta chamada de sistema especifica um arquivo existente 
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e um nome de caminho, e cria um vínculo (atalho) do arquivo existente com o 
nome especificado pelo caminho. Desse modo, o mesmo arquivo pode aparecer em 
vários diretórios. Um vínculo desse tipo, que incrementa o contador no i-node do 
arquivo (para monitorar o número de entradas de diretório contendo o arquivo), às 
vezes é chamado de vínculo estrito (hard link). 


8. Unlink. Uma entrada de diretório é removida. Se o arquivo que está sendo desvin- 
culado estiver presente apenas em um diretório (o caso normal), ele é removido do 
sistema de arquivos. Se ele estiver presente em vários diretórios, somente o nome de 
caminho especificado será removido. Os outros permanecem. Na verdade, no UNIX, 
a chamada de sistema para excluir arquivos (discutida anteriormente) é unlink. 


A lista anterior fornece as chamadas mais importantes, mas também existem algumas 
outras, por exemplo, para gerenciar as informações de proteção associadas a um diretório. 


IMPLEMENTAÇÃO DO SISTEMA DE ARQUIVOS 


Agora é hora de mudarmos da visão que o usuário tem do sistema de arquivos para a visão do 
projetista. Os usuários estão preocupados com a maneira pela qual os arquivos recebem seus 
nomes, quais operações são permitidas, como é a árvore de diretórios e questões semelhantes 
de interface. Os projetistas estão interessados em como arquivos e diretórios são armazena- 
dos, como o espaço em disco é gerenciado e em como fazer tudo funcionar de modo eficiente 
e confiável. Nas seções a seguir, examinaremos várias dessas áreas para vermos quais são os 
problemas e compromissos envolvidos. 


Layout do sistema de arquivos 


Normalmente, os sistemas de arquivos são armazenados em discos. Vimos o layout de um 
disco básico no Capítulo 2, na seção sobre a inicialização do MINIX 3. Revendo esse assunto 
sucintamente, a maioria dos discos pode ser dividida em partições, com sistemas de arquivos 
independentes em cada partição. O setor O do disco é chamado de MBR (Master Boot Re- 
cord — registro mestre de inicialização) e é usado para inicializar o computador. O final do 
MBR contém a tabela de partições. Essa tabela fornece os endereços inicial e final de cada 
partição. Uma das partições da tabela pode ser marcada como ativa. Quando o computador é 
inicializado, a BIOS lê e executa o código que está no MBR. A primeira ação do programa do 
MBR é localizar a partição ativa, ler seu primeiro bloco, chamado de bloco de inicialização 
(boot block), e executá-lo. O programa que está no bloco de inicialização carrega o sistema 
operacional contido nessa partição. Por homogeneidade, toda partição começa com um bloco 
de inicialização, mesmo que não contenha um sistema operacional que possa ser inicializado. 
Além disso, ela poderá futuramente conter um; portanto, de qualquer modo, reservar um blo- 
co de inicialização é uma boa idéia. 

A descrição anterior é verdadeira, independentemente do sistema operacional que está 
sendo usado, para qualquer plataforma de hardware na qual a BIOS é capaz de iniciar mais 
de um sistema operacional. A terminologia pode ser distinta entre os diferentes sistemas 
operacionais. Por exemplo, às vezes, o registro de inicialização mestre pode ser chamado de 
IPL (Initial Program Loader — carregador de programa inicial), Volume Boot Code (código 
de inicialização de volume) ou, simplesmente, masterboot. Alguns sistemas operacionais 
não exigem que uma partição seja marcada como ativa para serem inicializados e fornecem 
um menu para o usuário escolher uma partição a inicializar, as vezes com um tempo limite 
após o qual uma escolha padrão é feita automaticamente. Uma vez que a BIOS tenha car- 
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regado um MBR, ou setor de inicialização, as ações podem variar. Por exemplo, mais de 
um bloco de uma partição pode ser usado para conter o programa que carrega o sistema 
operacional. Só se pode contar com a BIOS para carregar o primeiro bloco, mas esse bloco 
pode, então, carregar mais blocos, se o projetista do sistema operacional escrever o bloco 
de inicialização dessa maneira. O projetista também pode fornecer um MBR personalizado, 
mas ele deve funcionar com uma tabela de partições padrão, caso sejam suportados vários 
sistemas operacionais. 

Em sistemas compatíveis com o PC não pode haver mais do que quatro partições pri- 
márias, pois há espaço apenas para um array de quatro elementos de descritores de parti- 
ção entre o registro de inicialização mestre e o final do primeiro setor de 512 bytes. Alguns 
sistemas operacionais permitem que uma entrada na tabela de partições seja uma partição 
estendida, a qual aponta para uma lista encadeada de partições lógicas. Isso torna possível 
ter qualquer número de partições adicionais. A BIOS não pode iniciar um sistema operacional 
a partir de uma partição lógica; portanto, a partida inicial de uma partição primária é exigida 
para carregar o código que pode gerenciar partições lógicas. 

Uma alternativa às partições estendidas é usada pelo MINIX 3, a qual permite que uma 
partição contenha uma tabela de subpartições. Uma vantagem disso é que o mesmo código 
que gerencia uma tabela de partições primárias pode gerenciar uma tabela de subpartições, 
que tem a mesma estrutura. Potenciais usos para as subpartições são: ter subpartições diferen- 
tes para o dispositivo-raiz, para swapping, para os binários do sistema e para os arquivos dos 
usuários. Desse modo, os problemas existentes em uma subpartição não se propagam para 
outra e uma nova versão do sistema operacional pode ser facilmente instalada por meio da 
substituição do conteúdo de algumas das subpartições, mas não de todas. 

Nem todos os discos são particionados. Os disquetes normalmente começam com um 
bloco de inicialização no primeiro setor. A BIOS lê o primeiro setor de um disco e procura 
um número mágico que o identifique como código executável válido, isso para impedir uma 
tentativa de executar o primeiro setor de um disco não formatado ou corrompido. Um registro 
de inicialização mestre e um bloco de inicialização usam o mesmo número mágico; portanto, 
o código executável pode estar em qualquer um deles. Além disso, o que dissemos aqui não 
está limitado aos dispositivos de disco eletromecânicos. Um equipamento, como uma câmara 
ou um assistente digital pessoal (PDA), que utilize memória não-volátil (por exemplo, flash), 
normalmente tem parte da memória organizada de forma a simular um disco. 

Fora o fato de iniciar com um bloco de inicialização, o layout de uma partição de disco 
varia consideravelmente de um sistema de arquivos para outro. Um sistema de arquivos do 
tipo UNIX conterá alguns dos itens mostrados na Figura 5-8. O primeiro deles é o superblo- 


<—— Disco inteiro 


Tabela de partição Partição do disco a 


Bloco de Gerenciamento ; RES ; , ad 
inicialização Superbloco | qe espaço livre i-nodes Diretório-raiz| Arquivos e diretórios 


Figura 5-8 Um possível layout de sistema de arquivos. 
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co (superblock). Ele contém todos os parâmetros importantes sobre o sistema de arquivos e 
é lido na memória quando o computador é inicializado ou quando o sistema de arquivos é 
usado pela primeira vez. 

Em seguida, vêm informações sobre os blocos livres no sistema de arquivos. Isso é 
seguido dos i-nodes, um array de estruturas de dados, uma entrada por arquivo, que fornece 
uma série de informações sobre os arquivos e onde seus blocos estão localizados no disco. 
Depois disso vem o diretório-raiz, que contém o topo da árvore do sistema de arquivos. Final- 
mente, o restante do disco normalmente contém todos os outros diretórios e arquivos. 


Implementando arquivos 


Provavelmente, a questão mais importante na implementação do armazenamento de arquivos 
é determinar quais blocos do disco pertencem a quais arquivos. Vários métodos são usados 
nos diferentes sistemas operacionais. Nesta seção, examinaremos alguns deles. 


Alocação contígua 


O esquema de alocação mais simples é armazenar cada arquivo como uma segiiência con- 
tígua de blocos do disco. Assim, em um disco com blocos de 1 KB, um arquivo de 50 KB 
alocaria 50 blocos consecutivos. A alocação contígua de espaço em disco tem duas vantagens 
significativas. Primeiro, ela é simples de implementar, pois o controle de onde estão os blocos 
de um arquivo fica reduzido a lembrar dois números: o endereço de disco do primeiro bloco 
e o número de blocos no arquivo. Dado o número do primeiro bloco, o número de qualquer 
outro bloco pode ser encontrado por uma simples adição. 

Segundo, o desempenho de leitura é excelente, pois o arquivo inteiro pode ser lido do 
disco em uma única operação. Apenas uma operação de busca (seek) é necessária (para o pri- 
meiro bloco). Depois disso, mais nenhuma busca (seek) ou atraso rotacional é necessário e os 
dados podem ser transferidos na largura de banda total do disco. Assim, a alocação contígua 
é simples de implementar e tem alto desempenho. 

Infelizmente, a alocação contígua também tem um inconveniente sério: com o tempo, 
o disco se torna fragmentado, consistindo em arquivos e lacunas. Inicialmente, essa frag- 
mentação não é problema, pois cada arquivo novo pode ser escrito no final do disco, após 
o anterior. Entretanto, finalmente o disco ficará cheio e se tornará necessário compactá-lo, 
o que é proibitivamente caro, para reutilizar o espaço livre das lacunas. Reutilizar o espaço 
exige manter uma lista de lacunas, o que é viável. Entretanto, quando um novo arquivo vai 
ser criado, é necessário saber seu tamanho final para escolher uma lacuna do tamanho correto 
para colocá-lo. 

Conforme mencionamos no Capítulo 1, a história pode se repetir na ciência da compu- 
tação, à medida que surgem novas gerações da tecnologia. A alocação contígua foi usada nos 
sistemas de arquivos de disco magnético há anos, devido a sua simplicidade e seu alto desem- 
penho (a facilidade de uso por parte do usuário não contava muito naquela época). Então, a 
idéia foi abandonada devido ao incômodo de ter de especificar o tamanho final do arquivo no 
momento de sua criação. Mas com o advento dos CD-ROMs, DVDs e outras mídias óticas 
de gravação única, repentinamente os arquivos contíguos se tornaram uma boa idéia outra 
vez. Para essa mídia, a alocação contígua é viável e, na verdade, amplamente usada. Aqui, 
todos os tamanhos de arquivo são conhecidos antecipadamente e não mudarão durante o uso 
subseqgiiente do sistema de arquivos do CD-ROM. Assim, é importante estudar os sistemas de 
arquivos e idéias antigas que eram conceitualmente limpos e simples, pois podem ser aplica- 
dos em sistemas futuros de maneiras surpreendentes. 
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Alocação encadeada 


O segundo método de armazenamento de arquivos é manter cada arquivo como uma lista 
encadeada de blocos de disco, como se vê na Figura 5-9. A primeira palavra de cada bloco é 
usada como um ponteiro para a próxima. O restante do bloco serve para dados. 


Arquivo A 


físico 


Figura 5-9 Armazenando um arquivo como uma lista encadeada de blocos de disco. 


Ao contrário da alocação contígua, neste método todos os blocos do disco podem ser 
usados. Nenhum espaço é perdido com fragmentação do disco (exceto quanto à fragmentação 
interna no último bloco de cada arquivo). Além disso, é suficiente que a entrada de diretório 
armazene simplesmente o endereço de disco do primeiro bloco. O restante pode ser encon- 
trado a partir dele 

Por outro lado, embora ler um arquivo segiiencialmente seja simples, o acesso alea- 
tório é extremamente lento. Para chegar ao bloco n, o sistema operacional tem de começar 
no início e ler os n — 1 blocos antes dele, um por vez. Claramente, fazer tantas leituras será 
demasiadamente lento. 

Além disso, o volume de armazenamento de dados em um bloco não é mais uma po- 
tência de dois, pois o ponteiro ocupa alguns bytes. Embora não seja fatal, ter um tamanho 
peculiar, é menos eficiente, pois muitos programas lêem e escrevem em blocos cujo tamanho 
é uma potência de dois. Com os primeiros bytes de cada bloco ocupados com um ponteiro 
para o próximo bloco, as leituras do tamanho do bloco inteiro exigem adquirir e concatenar 
informações de dois blocos do disco, o que gera sobrecarga extra devido à cópia. 


Alocação encadeada usando uma tabela na memória 


As duas desvantagens da alocação encadeada podem ser eliminadas pegando-se a palavra 
do ponteiro de cada bloco do disco e colocando-a em uma tabela na memória. A Figura 5-10 
mostra como é essa tabela para o exemplo da Figura 5-9. Nas duas figuras, temos dois arqui- 
vos. O arquivo A usa os blocos de disco 4, 7, 2, 10 e 12, nessa ordem, e o arquivo B usa os 
blocos de disco 6, 3, 11 e 14, nessa ordem. Usando a tabela da Figura 5-10, podemos começar 
com o bloco 4 e seguir o encadeamento até o fim. O mesmo pode ser feito começando no 
bloco 6. Os dois encadeamentos terminam com um marcador especial (por exemplo, —1) que 
não é um número de bloco válido. Essa tabela na memória principal é chamada de FAT (File 
Allocation Table — tabela de alocação de arquivo). 
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Bloco 
físico 
0 
2 
3 
4 —— O arquivo A começa aqui 
5 
6 —— O arquivo B começa aqui 
7 
8 
9 


15 O e Bloco não utilizado 


Figura 5-10 Alocação encadeada usando uma tabela de alocação de arquivo na memória 
principal. 


Nessa organização, o bloco inteiro está disponível para dados. Além disso, o acesso 
aleatório é muito mais fácil. Embora o encadeamento ainda deva ser seguido para encontrar 
determinado deslocamento dentro do arquivo, ele está inteiramente na memória, de modo que 
pode ser seguido sem necessidade de nenhuma referência de disco. Assim como o método 
anterior, é suficiente que a entrada de diretório mantenha um único valor inteiro (o número 
do bloco inicial) e ainda seja capaz de localizar todos os blocos, independente do tamanho 
do arquivo. 

A principal desvantagem desse método é que a tabela inteira precisa estar na memória 
o tempo todo. Com um disco de 20 GB e um tamanho de bloco de 1 KB, a tabela precisa de 
20 milhões de entradas, uma para cada um dos 20 milhões de blocos de disco. Cada entrada 
tem de ter no mínimo 3 bytes para manter o endereço de blocos. Para facilitar sua pesquisa, 
as entradas acabam ocupando 4 bytes. Assim, a tabela ocupará 60 MB ou 80 MB de memória 
principal o tempo todo, dependendo do sistema ser otimizado para espaço ou para tempo. 
Com certeza, a tabela poderia ser colocada de forma paginada em memória, mas ainda ocu- 
paria muita memória virtual e espaço em disco, assim como geraria tráfego de paginação. O 
MS-DOS e o Windows 98 usam apenas sistemas de arquivos FAT e as versões posteriores do 
Windows também os suportam. 


I-nodes 


Nosso último método para monitorar quais blocos pertencem a qual arquivo é associar a cada 
arquivo uma estrutura de dados chamada de i-node (nó-índice), a qual lista os atributos e en- 
dereços de disco dos blocos do arquivo. Um exemplo simples aparece na Figura 5-11. Dado o 
i-node, é possível então localizar todos os blocos do arquivo. A grande vantagem desse esque- 
ma em relação à alocação encadeada usando uma tabela na memória é que o i-node só precisa 
estar na memória quando o arquivo correspondente for aberto. Se cada i-node ocupa n bytes 
e no máximo k arquivos podem ser abertos por vez, a memória total ocupada pelo array que 
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contém os i-nodes para os arquivos abertos é de apenas kn bytes. Apenas esse espaço precisa 
ser reservado antecipadamente. 

Normalmente, esse array é bem menor do que o espaço ocupado pela tabela de arquivos 
descrita na seção anterior. O motivo é simples. A tabela para conter a lista encadeada de todos 
os blocos de disco tem um tamanho proporcional ao próprio disco. Se o disco tem n blocos, 
a tabela precisa de n entradas. À medida que os discos ficam maiores, essa tabela aumenta 
linearmente com eles. Em contraste, o esquema do i-node exige um array na memória cujo 
tamanho é proporcional ao número máximo de arquivos que podem ser abertos simultanea- 
mente. Não importa se o disco é de 1, 10 ou 100 GB. 

Um problema dos i-nodes é que, se cada um tiver espaço para um número fixo de ende- 
reços de disco, o que acontecerá quando um arquivo crescer além desse limite? Uma solução 
é reservar o último endereço do disco não para um bloco de dados, mas para o endereço de 
um bloco de indireção simples contendo mais endereços de bloco de disco. Essa idéia pode 
ser estendida para usar blocos indiretos duplos e blocos indiretos triplos, como se vê na 
Figura 5-11. 


I-node 

Atributos 

Es 
É = a 
Sid simples Endereços 
Dipo o Bloco psp 
pr ë o ë ë| indireto e dados 
a A i5 
S E aup 
S| p 
T 
e| p 
ES 

DD Bloco 

CS indireto 

E 


triplo 


Figura 5-11 Um i-node com três níveis de blocos indiretos. 


Implementando diretórios 


Antes que um arquivo possa ser lido, ele deve ser aberto. Quando um arquivo é aberto, o sis- 
tema operacional usa o nome de caminho fornecido pelo usuário para localizar a entrada de 
diretório. Localizar uma entrada de diretório significa, naturalmente, que o diretório-raiz deve 
ser localizado primeiro. O diretório-raiz pode estar em um local fixo relativo ao início de uma 
partição. Como alternativa, sua posição pode ser determinada a partir de outras informações; 
por exemplo, em um sistema de arquivos UNIX clássico, o superbloco contém informações 
sobre o tamanho das estruturas de dados do sistema de arquivos que precedem a área de da- 
dos. A partir do superbloco, a localização dos i-nodes pode ser encontrada. O primeiro i-node 
apontará para o diretório-raiz, que é criado quando um sistema de arquivos UNIX é feito. No 
Windows XP, as informações presentes no setor de inicialização (que, na verdade, é muito 
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maior do que um setor) localizam a MFT (Master File Table — tabela de arquivos mestra), 
que é usada para localizar outras partes do sistema de arquivos. 

Uma vez localizado o diretório-raiz, uma pesquisa na árvore de diretórios localiza a 
entrada de diretório desejada. A entrada de diretório fornece a informação necessária para en- 
contrar os blocos de disco do arquivo associado a essa entrada. Dependendo do sistema, essa 
informação pode ser o endereço de disco do arquivo inteiro (alocação contígua), o número 
do primeiro bloco (os dois esquemas de lista encadeada) ou o número do i-node. Em todos 
os casos, a função principal do sistema de diretório é fazer o mapeamento do nome ASCII do 
arquivo para as informações necessárias para localizar os dados. 

Uma questão intimamente relacionada é onde os atributos devem ser armazenados. 
Todo sistema de arquivos mantém atributos de arquivo, como o proprietário e a hora de cria- 
ção de cada arquivo, e eles devem ser armazenados em algum lugar. Uma possibilidade óbvia 
é armazená-los diretamente na entrada de diretório. Em sua forma mais simples, um diretório 
consiste em uma lista de entradas de tamanho fixo, uma por arquivo, contendo um nome de 
arquivo (de tamanho fixo), uma estrutura dos atributos do arquivo e um ou mais endereços 
de disco (até algum máximo) informando onde estão os blocos de disco, conforme vimos na 
Figura 5-5(a). 

Para sistemas que usam i-nodes, outra possibilidade para o armazenamento dos atribu- 
tos é nos i-nodes, em vez de usar as entradas de diretório, como se vê na Figura 5-5(b). Nesse 
caso, a entrada de diretório pode ser mais curta: apenas um nome de arquivo e um número de 
i-node. 


Arquivos compartilhados 


No Capítulo 1, mencionamos brevemente os vínculos (links) entre arquivos, os quais tornam 
fácil o compartilhamento de arquivos por vários usuários que estejam trabalhando em um 
projeto. A Figura 5-12 mostra o sistema de arquivos da Figura 5-6(c) novamente, apenas que, 
agora, com os arquivos de C presentes também em um dos diretórios de B. 


Arquivo compartilhado 


Figura 5-12 Sistema de arquivos contendo um arquivo compartilhado. 


No UNIX, o uso de i-nodes para armazenar atributos de arquivo facilita o comparti- 
lhamento; qualquer número de entradas de diretório pode apontar para um único i-node. O 
i-node contém um campo que é incrementado quando um novo vínculo é adicionado e que é 
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Bytes 


Figura 5- 


decrementado quando um vínculo é excluído. Somente quando a contagem de vínculos chega 
à zero é que os dados reais e o i-node em si são excluídos. 

Esse tipo de vínculo às vezes é chamado de vínculo estrito (hard link). Nem sempre é 
possível o compartilhamento de arquivos usando vínculos estritos. Uma limitação importante 
é que os diretórios e i-nodes são estruturas de dados de um único sistema de arquivos (parti- 
ção); portanto, um diretório em um sistema de arquivos não pode apontar para um i-node em 
outro sistema de arquivos. Além disso, um arquivo só pode ter um proprietário e um conjunto 
de permissões. Se o proprietário de um arquivo compartilhado excluir sua própria entrada de 
diretório para esse arquivo, outro usuário poderá ficar preso com um arquivo em seu diretório 
que não pode excluir, caso as permissões não o autorizem a isso. 

Uma maneira alternativa de compartilhar arquivos é criar um novo tipo de arquivo cujos 
dados sejam o caminho para outro arquivo. Esse tipo de vínculo funciona entre sistemas de 
arquivos montados. Na verdade, se for providenciada uma maneira de os nomes de caminho 
incluírem endereços de rede, esse vínculo poderá se referir a um arquivo em outro computa- 
dor. Esse segundo tipo de vínculo é chamado de vínculo simbólico (soft link) nos sistemas 
do tipo UNIX, de atalho no Windows e de alias no Mac OS da Apple. Os vínculos simbó- 
licos podem ser usados nos sistemas onde os atributos são armazenados dentro das entradas 
de diretório. Pensando um pouco, você deverá se convencer de que seria difícil sincronizar 
várias entradas de diretório contendo atributos de arquivo. Qualquer mudança em um arquivo 
teria de afetar todas as entradas de diretório desse arquivo. Mas as entradas de diretório ex- 
tras para vínculos simbólicos não contêm os atributos do arquivo para o qual apontam. Uma 
desvantagem dos vínculos simbólicos é que, quando um arquivo é excluído ou mesmo apenas 
renomeado, um vínculo se torna órfão. 


Diretórios no Windows 98 


O sistema de arquivos da versão original do Windows 95 era idêntico ao sistema de arquivos 
do MS-DOS, mas uma segunda versão acrescentou suporte para nomes e arquivos maiores. 
Vamos nos referir a ele como sistema de arquivos do Windows 98, mesmo sendo encontrado 
em alguns sistemas Windows 95. Existem dois tipos de entrada de diretório no Windows 98. 
Vamos chamar a primeira, mostrado na Figura 5-13, de entrada de base. 


8 3 1 4 2 2 4 2 
Ext N Data/hora mo Data/hora da 
Em 


4 
Tamanho 
do arquivo 


Atributos ; . 
Segundos 16 bits 16 bits 
superiores do inferiores do 
bloco inicial bloco inicial 


13 Uma entrada de diretório de base do Windows 98. 


A entrada de diretório de base tem todas as informações que havia nas entradas de di- 
retório das versões mais antigas do Windows e muitas outras. Os 10 bytes a partir do campo 
NT foram acrescentados na estrutura do antigo Windows 95, que felizmente (ou, é mais pro- 
vável, deliberadamente, com um aprimoramento posterior em mente) não foram usadas antes. 
A modificação mais importante é o campo que aumenta o número de bits disponíveis para 
apontar para o bloco inicial, de 16 para 32. Isso aumenta o tamanho máximo em potencial do 
sistema de arquivos de 2'º blocos para 2” blocos. 

Essa estrutura é preparada apenas para os nomes de arquivo do antigo estilo de 8 + 3 
caracteres, herdados do MS-DOS (e do CP/M). E quanto aos nomes de arquivo longos? A res- 
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posta para o problema de fornecer nomes de arquivo longos, enquanto se mantém a compati- 
bilidade com os sistemas mais antigos, foi usar entradas de diretório adicionais. A Figura 5-14 
mostra uma forma alternativa de entrada de diretório para conter até 13 caracteres de um nome 
de arquivo longo. Para arquivos com nomes longos, uma forma reduzida do nome é gerada au- 
tomaticamente e colocada nos campos Nome de base e Ext de uma entrada de diretório de base 
no estilo da Figura 5-13. Tantas entradas como a da Figura 5-14 quantas forem necessárias 
para conter o nome de arquivo longo, são colocadas antes da entrada de base, em ordem inver- 
sa. O campo Atributos de cada entrada de nome longo contém o valor 0xOF, que é um valor 
impossível para sistemas de arquivos mais antigos (MS-DOS e Windows 95); portanto, essas 
entradas serão ignoradas se o diretório for lido por um sistema mais antigo (em um disquete, 
por exemplo). Um bit no campo Segiiência informa ao sistema qual é a última entrada. 


Bytes 1 10 12 2 4 


1 1 1 
J ee p eee To pre 


Seqüência Atributos 


Soma de verificação 


Figura 5-14 Uma entrada para (parte de) um nome de arquivo longo no Windows 98. 


Se isso parece muito complexo, bem, é mesmo. É complicado fornecer compatibilidade 
com versões anteriores para que um sistema mais simples possa continuar a funcionar, en- 
quanto se fornece recursos adicionais para um sistema mais recente. Um purista pode optar 
por não ter tantos problemas. Entretanto, um purista provavelmente não se tornaria rico ven- 
dendo novas versões dos sistemas operacionais. 


Diretórios no UNIX 


A estrutura de diretório tradicional do UNIX é extremamente simples, como se vê na Figura 
5-15. Cada entrada contém apenas um nome de arquivo e seu número de i-node. Todas as 
informações sobre tipo, tamanho, tempos, propriedade e blocos de disco estão contidas no i- 
node. Alguns sistemas UNIX têm um layout diferente, mas em todos os casos uma entrada de 
diretório contém, em última análise, apenas uma string em ASCII e um número de i-node. 


Bytes 2 14 
| Mewan | 
Número 
do i-node 


Figura 5-15 Uma entrada de diretório do UNIX Versão 7. 


Quando um arquivo é aberto, o sistema de arquivos deve pegar o nome de arquivo 
fornecido e localizar seus blocos de disco. Vamos considerar como o nome de caminho /usr/ 
ast/mbox é pesquisado. Usaremos o UNIX como exemplo, mas o algoritmo é basicamente o 
mesmo para todos os sistemas de diretório hierárquicos. Primeiramente, o sistema localiza o 
diretório-raiz. Os i-nodes formam um array simples que é localizado usando-se as informa- 
ções presentes no superbloco. A primeira entrada nesse array é o i-node do diretório-raiz. 
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O sistema de arquivos pesquisa o primeiro componente do caminho, usr, no diretório- 
raiz para encontrar o número do i-node do arquivo /usr/. Localizar um i-node a partir de seu 
número é simples, pois cada um tem uma localização fixa relativa ao primeiro. A partir desse 
i-node, o sistema localiza o diretório de /usr/ e pesquisa nele o próximo componente, ast. 
Quando tiver encontrado a entrada de ast, ele terá o i-node do diretório /usr/ast/. A partir 
desse i-node, ele pode encontrar o diretório em si e pesquisar mbox. Então, o i-node desse 
arquivo é lido na memória e mantido nela até que o arquivo seja fechado. O processo de pes- 
quisa está ilustrado na Figura 5-16. 


O bloco O i-node O bloco 406 
O i-node 132 é0 26é0 é o diretório 
Diretório-raiz 6 é o /usr diretório /usr /usr/ast /usr/ast 


we || ES 
tamanho a fe tamanho EM 
ia ida 


E 


O i-node O i-node 26 
A pesquisa 6 diz que /usr/ast diz que /ust/ast/mbox 
de usr resulta /usr está no éo /usr/ast está é o i-node 
no i-node 6 bloco 132 i-node 26 no bloco 406 60 


Figura 5-16 Os passos na pesquisa de /usr/ast/mbox. 


Os nomes de caminho relativos são pesquisados da mesma maneira que os absolutos, 
somente que a partir do diretório de trabalho, em vez do diretório-raiz. Todo diretório tem 
entradas para . e .., que são colocadas lá quando o diretório é criado. A entrada . tem o nú- 
mero do i-node do diretório corrente e a entrada de .. tem o número do i-node do diretório 
pai. Assim, uma busca por ../dick/prog.c pesquisará simplesmente .. no diretório de trabalho, 
encontrará o número do i-node do diretório pai e procurará esse diretório em busca de dick. 
Nenhum mecanismo especial é necessário para tratar desses nomes. No que diz respeito ao 
sistema de diretório, eles são apenas strings ASCII normais, exatamente iguais a qualquer 
outro nome. 


Diretórios no NTFS 


O NTFS (New Technology File System) da Microsoft é o sistema de arquivos padrão das 
novas versões do Windows. Não temos espaço para uma descrição detalhada do NTFS, mas 
veremos brevemente alguns dos problemas que ele trata e as soluções utilizadas. 

Um problema são os nomes de arquivo e de caminho longos. O NTFS permite nomes 
de arquivo longos (até 255 caracteres) e nomes de caminho longos (até 32.767 caracteres). 
Mas, como as versões antigas do Windows não podem ler sistemas de arquivos NTFS, não 
é necessária uma estrutura de diretório complicada compatível com versões anteriores e os 
campos de nome de arquivo têm comprimento variável. Foram feitos preparativos para ter um 
segundo nome de 8 + 3 caracteres, para que um sistema mais antigo possa acessar arquivos 
NTES via rede. 
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5.3.4 


O NTFS fornece vários conjuntos de caracteres, usando Unicode para nomes de arquivo. 
O Unicode usa 16 bits para cada caractere, que são suficientes para representar vários idiomas 
com conjuntos de símbolos muito grandes (por exemplo, o japonês). Mas usar vários idio- 
mas acarreta problemas, além da representação de diferentes conjuntos de caracteres. Mesmo 
entre os idiomas derivados do latim existem sutilezas. Por exemplo, no idioma espanhol, 
algumas combinações de dois caracteres contam como caracteres simples, quando ordenadas. 
As palavras que começam com “ch” ou “II” devem aparecer nas listas ordenadas depois das 
palavras que começam com “cz” ou “lz”, respectivamente. O problema do mapeamento da 
caixa alta e baixa é mais complexo. Se o padrão é fazer os nomes de arquivo diferenciar letras 
maiúsculas e minúsculas, ainda pode haver necessidade de fazer pesquisas que não as levam 
em consideração. Para idiomas baseados no latim, o modo de fazer isso é evidente, pelo me- 
nos para usuários nativos desses idiomas. Em geral, se apenas um idioma estiver sendo usado, 
os usuários provavelmente conhecerão as regras. Entretanto, o Unicode permite uma mistura 
de idiomas: Nomes de arquivo em grego, russo e japonês poderiam aparecer todos em um 
único diretório em uma organização internacional. A solução do NTFS é um atributo para 
cada arquivo, que define as convenções de caixa para o idioma do nome de arquivo. 

A solução do NTFS para muitos problemas é adicionar mais atributos. No UNIX, um 
arquivo é uma seqiiência de bytes. No NTFS, um arquivo é um conjunto de atributos e cada 
atributo é um fluxo (stream) de bytes. A estrutura de dados básica do NTFS é a MFT (Master 
File Table — tabela de arquivos mestra), que fornece 16 atributos, cada um dos quais podendo 
ter um comprimento de até 1 KB dentro da MFT. Se isso não for suficiente, um atributo den- 
tro da MFT pode ser um cabeçalho apontando para um arquivo adicional com uma extensão 
dos valores de atributo. Isso é conhecido como atributo não-residente. A própria MFT é um 
arquivo e tem uma entrada para cada arquivo e cada diretório no sistema de arquivos. Como 
ela pode ficar muito grande, quando um sistema de arquivos NTFS é criado, cerca de 12,5% 
do espaço na partição são reservados para o crescimento da MFT. Assim, ela pode crescer 
sem se fragmentar, pelo menos até que o espaço inicial reservado seja usado, após o que outro 
grande trecho de espaço será reservado. Portanto, se a MFT se fragmentar, ela consistirá em 
um pequeno número de fragmentos muito grandes. 

E quanto aos dados no NTFS? Os dados são apenas outro atributo. Na verdade, um ar- 
quivo NTFS pode ter mais de um fluxo de dados. Essa característica foi fornecida originalmen- 
te para permitir que servidores Windows enviassem arquivos para clientes Apple MacIntosh. 
No sistema operacional original do MacIntosh (até o Mac OS 9), todos os arquivos tinham dois 
fluxos de dados, chamados de bifurcação de recursos e de bifurcação de dados. Vários fluxos 
de dados têm outros usos; por exemplo, uma imagem gráfica grande pode ter uma imagem em 
miniatura menor associada. Um fluxo pode conter até Ag bytes. No outro extremo, o NTFS 
pode manipular arquivos pequenos colocando algumas centenas de bytes no cabeçalho do atri- 
buto. Isso é chamado de arquivo imediato (Mullender e Tanenbaum, 1984). 

Apenas mencionamos algumas maneiras pelas quais o NTFS trata das questões não 
resolvidas pelos sistemas de arquivos mais antigos e simples. O NTFS também fornece recur- 
sos como um sistema de proteção sofisticado, criptografia e compactação de dados. Descrever 
todos esses recursos e sua implementação exigiria muito mais espaço do que podemos dispor 
aqui. Para ver mais completamente o NTFS, consulte Tanenbaum (2001) ou procure mais 
informações na web. 


Gerenciamento do espaço em disco 


Normalmente, os arquivos são armazenados no disco, de modo que o gerenciamento do espa- 
ço em disco é uma preocupação importante para os projetistas de sistema de arquivos. Duas 
estratégias gerais são possíveis para armazenar um arquivo de n bytes: são alocados n bytes 
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consecutivos de espaço em disco ou o arquivo é dividido em vários blocos (não necessaria- 
mente) contíguos. O mesmo compromisso está presente nos sistemas de gerenciamento de 
memória entre usar segmentação pura e paginação. 

Conforme vimos, armazenar um arquivo como uma seqiiência contígua de bytes tem o 
problema óbvio de que, se um arquivo crescer, provavelmente terá de ser movido no disco. 
O mesmo problema vale para os segmentos na memória, exceto que mover um segmento na 
memória é uma operação relativamente rápida, comparada a mover um arquivo de uma posi- 
ção para outra no disco. Por isso, quase todos os sistemas de arquivos dividem os arquivos em 
blocos de tamanho fixo que não precisam ser contíguos. 


Tamanho do bloco 


Uma vez decidido que os arquivos serão armazenados em blocos de tamanho fixo, surge a 
questão do tamanho que os blocos devem ter. Dada a maneira como os discos são organiza- 
dos, o setor, a trilha e o cilindro são candidatos óbvios para a unidade de alocação (embora 
todos eles sejam dependentes do dispositivo, o que é ruim). Em um sistema de paginação, o 
tamanho da página também é um candidato importante. Entretanto, ter uma unidade de alo- 
cação grande, como um cilindro, significa que todo arquivo, mesmo um arquivo de 1 byte, 
ocupa um cilindro inteiro. 

Por outro lado, usar uma unidade de alocação pequena significa que cada arquivo con- 
sistirá em muitos blocos. Ler cada bloco normalmente exige uma busca (seek) e um atraso 
rotacional; portanto, será lento ler um arquivo consistindo em muitos blocos pequenos. 

Como exemplo, considere um disco com 131.072 bytes/trilha, um tempo de rotação de 
8,33 ms e um tempo de busca médio de 10 ms. Então, o tempo em milissegundos para ler um 
bloco de k bytes é a soma dos tempos de busca, do atraso rotacional e da transferência: 


10 + 4,165 + (k/131072) x 8,33 


A curva em linha cheia da Figura 5-17 mostra a taxa de transferência de dados para esse 
disco como uma função do tamanho do bloco. 

Para calcular a eficiência do espaço, precisamos fazer uma suposição a respeito do ta- 
manho de arquivo médio. Um estudo anterior mostrou que o tamanho de arquivo médio nos 
ambientes UNIX é de cerca de 1 KB (Mullender e Tanenbaum, 1984). Uma medida feita em 
2005, no departamento de um dos autores (AST), que tem 1000 usuários e mais de 1 milhão 
de arquivos UNIX em disco, forneceu um tamanho mediano de 2475 bytes, significando que 
metade dos arquivos é menor do que 2475 bytes e metade, maior. Além disso, a mediana 
é uma métrica melhor do que a média, pois um número muito pequeno de arquivos pode 
influenciar enormemente a média, mas não a mediana. Alguns manuais de hardware com ta- 
manhos de 100 MB, ou vídeos promocionais, podem distorcer muito a média, mas têm pouco 
efeito sobre a mediana. 

Em uma experiência para ver se a utilização de arquivo do Windows NT era considera- 
velmente diferente da utilização de arquivo do UNIX, Vogels (1999) fez medidas em arquivos 
na Universidade de Cornell. Ele observou que a utilização de arquivo do NT é mais compli- 
cada do que no UNIX. Ele escreveu: 


Quando digitamos alguns caracteres no editor de textos notepad, salvar isso em 
um arquivo acarreta 26 chamadas de sistema, incluindo 3 tentativas de abertura 
falhas, 1 arquivo sobrescrito e 4 segiiências de abertura e fechamento adicio- 
nais. 


Contudo, ele observou um tamanho mediano (ponderado pela utilização) de 1 KB para 
arquivos apenas de leitura, de 2,3 KB para arquivos apenas de escrita e de 4,2 KB para arqui- 


CaríTuLO 5 e SISTEMA DE ARQUIVOS 471 


vos de leitura e escrita. Dado o fato que a Universidade de Cornell faz computação científica 
em larga escala de forma considerável e a diferença na técnica de medida (estática versus di- 
nâmica), os resultados são razoavelmente consistentes com um tamanho de arquivo mediano 
de cerca de 2 KB. 

Por simplicidade, vamos supor que todos os arquivos têm 2 KB, o que leva à curva tra- 
cejada da Figura 5-17 para a eficiência do espaço em disco. 


—e- cen nen ne — 100 


Utilização do espaço em disco ` 


Taxa de dados (KB/s) 
Utilização do espaço em disco 
(porcentagem) 


Taxa de transferência de dados 


(0) 128 256 512 1K 2K 4K 8K 16K 0 
Tamanho do bloco (bytes) 


Figura 5-17 A curva em linha cheia (escala da esquerda) fornece a taxa de transferência de 
dados de um disco. A curva tracejada (escala da direita) fornece a eficiência do espaço em 
disco. Todos os arquivos têm 2 KB. 


As duas curvas podem ser entendidas como segue. O tempo de acesso para um bloco 
é fortemente influenciado pelo tempo de busca e pelo atraso rotacional; portanto, dado que 
vai custar 14 ms para acessar um bloco, quanto mais dados forem lidos, melhor. Portanto, a 
taxa de transferência de dados aumenta com o tamanho do bloco (até que as transferências 
demorem tanto que o tempo de transferência comece a dominar). Com blocos pequenos, 
que são potências de dois, e arquivos de 2 KB, nenhum espaço é desperdiçado em um bloco. 
Entretanto, com arquivos de 2 KB e blocos de 4 KB ou maiores, certo espaço em disco é 
desperdiçado. Na realidade, alguns arquivos são um múltiplo do tamanho do bloco no disco; 
portanto, algum espaço sempre é desperdiçado no último bloco de um arquivo. 

Entretanto, o que as curvas mostram é que o desempenho e a utilização de espaço estão 
inerentemente em conflito. Blocos pequenos são ruins para o desempenho, mas bons para a 
utilização do espaço em disco. É necessário um tamanho de meio-termo. Para esses dados, 4 
KB poderia ser uma boa escolha, mas alguns sistemas operacionais fizeram suas escolhas há 
muito tempo, quando os parâmetros do disco e os tamanhos de arquivo eram diferentes. Para 
o UNIX, 1 KB é comumente usado. Para o MS-DOS, o tamanho do bloco pode ser qualquer 
potência de dois, de 512 bytes a 32 KB, mas é determinado pelo tamanho do disco e por mo- 
tivos não relacionados a esses argumentos (o número máximo de blocos em uma partição de 
disco é de 2º, o que impõe blocos grandes em discos grandes). 


Monitorando os blocos livres 


Uma vez escolhido o tamanho do bloco, a próxima questão é como manter a informação 
de quais são os blocos livres. Dois métodos, que aparecem na Figura 5-18, são amplamente 
usados. O primeiro consiste em usar uma lista encadeada de blocos de disco, com cada blo- 
co contendo tantos quantos números de bloco de disco livre couberem. Com um bloco de 1 
KB e um número de bloco de disco de 32 bits, cada bloco na lista de regiões livres contém 
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5.3.5 


os números de 255 blocos livres. (Uma entrada é necessária para o ponteiro para o próximo 
bloco). Um disco de 256 GB precisa de uma lista de regiões livres de no máximo 1.052.689 
blocos para conter todos os 2* números de bloco de disco. Fregiientemente, os blocos livres 
são usados para conter a lista de regiões livres. 


Blocos de disco livres: 16, 17, 18 


0000111011010111 
1011101101101111 
1100100011101111 


0111011101110111 
1101111101110111 


Um bloco de disco de 1 KB pode Mapa de bits 
conter 256 números de bloco 
de disco de 32 bits (a) (b) 


Figura 5-18 (a) Armazenando a lista de regiões livres em uma lista encadeada. (b) Um 
mapa de bits. 


A outra técnica de gerenciamento do espaço livre é o mapa de bits. Um disco com n blo- 
cos exige um mapa de bits com n bits. Os blocos livres são representados pelos valores 1 no 
mapa, os blocos alocados, pelos valores O (ou vice-versa). Um disco de 256 GB tem 2* blo- 
cos de 1 KB e, assim, exige 2” bits para o mapa, o que exige 32.768 blocos. Não é surpresa o 
fato de o mapa de bits exigir menos espaço, pois ele utiliza 1 bit por bloco, versus 32 bits no 
modelo da lista encadeada. Somente se o disco estiver praticamente cheio (isto é, tiver poucos 
blocos livres) é que o esquema da lista encadeada exigirá menos blocos do que o mapa de 
bits. Por outro lado, se houver muitos blocos livres, alguns deles poderão ser emprestados 
para conter a lista de regiões livres sem nenhuma perda da capacidade do disco. 

Quando é usado o método da lista de regiões livres, apenas um bloco de ponteiros preci- 
sa ser mantido na memória principal. Quando um arquivo é criado, os blocos necessários são 
tirados do bloco de ponteiros. Quando não tiver mais, um novo bloco de ponteiros é lido do 
disco. Analogamente, quando um arquivo é excluído, seus blocos são liberados e adicionados 
ao bloco de ponteiros na memória principal. Quando esse bloco é preenchido, ele é escrito 
no disco. 


Confiabilidade do sistema de arquivos 


A destruição de um sistema de arquivos é frequentemente um desastre muito maior do que 
a destruição de um computador. Se um computador é destruído por causa de um incêndio, 
sobretensão devida a raios ou uma xícara de café derramada no teclado, isso é irritante e custa 
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dinheiro, mas geralmente uma peça de reposição pode ser adquirida sem muitos problemas. 
Os computadores pessoais baratos podem até ser substituídos dentro de poucas horas (exceto 
nas universidades, onde emitir uma ordem de compra exige a anuência de três comitês, cinco 
assinaturas e 90 dias), bastando ir até uma loja para comprar. 

Se o sistema de arquivos de um computador for irrevogavelmente perdido, seja devido 
ao hardware, ao software ou ratos roendo as fitas de backup, restaurar todas as informações 
será, na melhor das hipóteses, difícil e demorado, e em muitos casos, impossível. Para as pes- 
soas cujos programas, documentos, arquivos de clientes, registros de imposto, bancos de da- 
dos, planos de marketing ou outros dados perderam-se para sempre, as consegiiências podem 
ser catastróficas. Embora o sistema de arquivos não possa oferecer nenhuma proteção contra 
a destruição física do equipamento e da mídia, ele pode ajudar a proteger as informações. 
Nesta seção, veremos alguns dos problemas envolvidos na proteção do sistema de arquivos. 

Os disquetes geralmente estão perfeitos quando saem da fábrica, mas podem revelar 
blocos defeituosos durante o uso. Pode-se dizer que isso é mais provável agora do que quando 
os disquetes eram mais utilizados. As redes e os dispositivos removíveis de grande capacida- 
de, como os CDs graváveis, fazem com que os disquetes sejam menos utilizados. As ventoi- 
nhas drenam o ar e transportam poeira para dentro das unidades de disquete e uma unidade 
de disco que não foi utilizada por um longo tempo pode ficar tão suja, a ponto de arruinar o 
próximo disco que for inserido. Uma unidade de disquete usada frequentemente tem menos 
probabilidade de danificar um disco. 

Os discos rígidos freqiientemente têm blocos defeituosos desde o início: é simplesmen- 
te dispendioso demais fabricá-los completamente livres de todos os defeitos. Conforme vi- 
mos no Capítulo 3, os blocos defeituosos em discos rígidos geralmente são tratados pela con- 
troladora por meio da substituição de setores danificados por sobressalentes fornecidos para 
esse propósito. Nesses discos, as trilhas são pelo menos um setor maior do que o necessário, 
para que pelo menos um ponto defeituoso possa ser pulado, deixando-o em uma lacuna entre 
dois setores consecutivos. Alguns setores sobressalentes são fornecidos em cada cilindro para 
que a controladora possa fazer o remapeamento automático de setores, caso perceba que um 
setor precisa de mais do que certo número de tentativas para ser lido ou escrito. Assim, o 
usuário normalmente não sabe da existência de blocos defeituosos ou de seu gerenciamento. 
Contudo, quando um disco IDE ou SCSI moderno falhar, normalmente a falha será grave, 
porque esgotaram-se os setores sobressalentes. Os discos SCSI fornecem um aviso de “erro 
recuperado” quando fazem o remapeamento de um bloco. Se o driver notar isso e exibir uma 
mensagem no monitor, o usuário saberá que é hora de comprar um novo disco, quando essas 
mensagens começarem a aparecer fregiientemente. 

Existe uma solução de software simples para o problema do bloco danificado, conve- 
niente para uso em discos mais antigos. Essa estratégia exige que o usuário, ou o sistema de 
arquivos, construa cuidadosamente um arquivo contendo todos os blocos defeituosos. Essa 
técnica os remove da lista de regiões livres, de modo que nunca ocorrerão em arquivos de 
dados. Contanto que o arquivo de blocos danificado nunca seja lido nem escrito, não haverá 
problema algum. É preciso tomar cuidado durante os backups de disco, para evitar a leitura 
desse arquivo e a tentativa de fazer seu backup. 


Backups 


A maioria das pessoas não acha que fazer backups de seus arquivos vale o tempo e o trabalho 
necessários — até que um belo dia, seu disco estraga repentinamente, quando então a maioria 
delas se arrepende de não ter aproveitado para fazer backup nos últimos momentos de vida 
do disco. Entretanto, as empresas (normalmente) entendem bem o valor de seus dados e ge- 
ralmente fazem backup pelo menos uma vez ao dia, normalmente em fita. As fitas modernas 
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armazenam dezenas ou, às vezes, até centenas de gigabytes e custam pouco por gigabyte. 
Contudo, fazer backups não é tão simples quanto parece; portanto, a seguir, examinaremos 
algumas das questões relacionadas. 

Os backups em fita geralmente são feitos para tratar de um de dois problemas em po- 
tencial: 


1. Recuperação de um desastre. 


2. Recuperação de uma estupidez. 


O primeiro consiste em fazer com que o computador funcione novamente, após uma 
falha de disco, um incêndio, uma inundação ou outra catástrofe natural. Na prática, essas coi- 
sas não acontecem muito frequentemente e esse é o motivo pelo qual muitas pessoas não se 
preocupam com os backups. Essas pessoas também tendem a não ter seguro contra incêndio 
para suas casas, pelo mesmo motivo. 

O segundo motivo é que, muitas vezes, os usuários removem acidentalmente arquivos que 
depois precisam novamente. Esse problema ocorre com tanta frequência que quando um arqui- 
vo é removido no Windows, ele não é realmente excluído, mas apenas movido para um diretório 
especial, a lixeira (recycle bin), para que depois possa ser buscado e restaurado rapidamente. 
Os backups levam esse princípio mais adiante e permitem que arquivos que foram removidos 
há dias, ou mesmo há semanas atrás, sejam restaurados a partir de fitas de backup antigas. 

Fazer um backup leva um longo tempo e ocupa uma grande quantidade de espaço; 
portanto, é importante fazê-lo eficiente e convenientemente. Essas considerações levantam 
as seguintes perguntas. Primeiramente, deve-se fazer o backup do sistema de arquivos inteiro 
ou apenas de parte dele? Em muitas instalações, os programas executáveis (binários) são 
mantidos em uma parte limitada da árvore do sistema de arquivos. Não é necessário fazer o 
backup desses arquivos, caso eles possam ser todos reinstalados a partir dos CD-ROMs dos 
fabricantes. Além disso, a maioria dos sistemas tem um diretório para arquivos temporários. 
Normalmente, também não há motivos para fazer backup deles. No UNIX, todos os arquivos 
especiais (dispositivos de E/S) são mantidos em um diretório /dev/. Não apenas o backup 
desse diretório não é necessário, como também é muito perigoso, pois o programa de backup 
travaria para sempre se tentasse ler cada um deles até o fim. Em suma, normalmente é dese- 
jável fazer backup apenas de diretórios específicos e de tudo que há neles, em vez do sistema 
de arquivos inteiro. 

Segundo, é um desperdício fazer backup de arquivos que não mudaram desde o último 
backup, o que leva à idéia dos backups incrementais. A forma mais simples de backup incre- 
mental é fazer um backup completo periodicamente, digamos, semanalmente ou mensalmen- 
te, e fazer um backup diário apenas dos arquivos que foram modificados desde o último ba- 
ckup completo. Embora esse esquema minimize o tempo de backup, ele torna a recuperação 
mais complicada, porque primeiro é necessário restaurar o backup completo mais recente, 
seguido de todos os backups incrementais na ordem inversa, ou seja, o mais antigo primeiro. 
Para facilitar a recuperação, freqiientemente são usados esquemas de backup incremental 
mais sofisticados. 

Terceiro, como o backup normalmente envolve imensos volumes de dados, talvez seja 
desejável compactá-los antes de gravá-los em fita. Entretanto, em muitos algoritmos de com- 
pactação, um único ponto defeituoso na fita de backup pode fazer o algoritmo de descompac- 
tação desandar e tornar o arquivo inteiro ou mesmo uma fita inteira ilegível. Assim, a decisão 
de compactar o fluxo de backup deve ser cuidadosamente considerada. 

Quarto, é difícil fazer um backup em um sistema de arquivos em uso. Se arquivos e 
diretórios estiverem sendo adicionados, excluídos e modificados durante o processo de ba- 
ckup, o resultado poderá ser inconsistente. Entretanto, como fazer um backup pode demorar 
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várias horas, talvez seja necessário deixar o sistema off-line grande parte da noite para fazer 
o backup, algo que nem sempre é aceitável. Por isso, foram elaborados algoritmos para tirar 
rápidos instantâneos do estado do sistema de arquivos, copiando estruturas de dados críticas 
e então exigindo que as futuras alterações nos arquivos e diretórios copiem os blocos, em 
vez de atualizá-los no local (Hutchinson et al., 1999). Desse modo, o sistema de arquivos 
fica efetivamente congelado no momento do instantâneo, para que o backup possa ser feito 
trangiiilamente. 

Quinto e último, fazer backups introduz muitos problemas não-técnicos em uma orga- 
nização. O melhor sistema de segurança on-line do mundo pode ser inútil se o administrador 
do sistema mantiver todas as fitas de backup em seu escritório e deixá-lo aberto e sem vigi- 
lância ao sair para pegar a saída da impressora. Tudo que um espião precisa fazer é entrar 
por um segundo, colocar uma pequena fita em seu bolso e sair rapidinho. Adeus segurança. 
Além disso, fazer um backup diário não será muito útil se um incêndio que venha a queimar 
os computadores queime também todas as fitas de backup. Por isso, as fitas de backup devem 
ser guardadas em outro lugar, mas isso introduz mais riscos para a segurança. Para ver uma 
discussão completa sobre essas e outras questões práticas de administração, consulte Nemeth 
et al. (2001). A seguir, discutiremos apenas as questões técnicas envolvidas nos backups do 
sistema de arquivos. 

Duas estratégias podem ser usadas para copiar um disco em fita: uma cópia física ou 
uma cópia lógica. A cópia física começa no bloco 0 do disco, grava todos os blocos de disco 
na fita de saída, em ordem, e pára quando tiver copiado o último. Esse programa é tão simples 
que provavelmente pode ser executado 100% sem erros, algo que possivelmente não se pode 
dizer a respeito de nenhum outro programa útil. 

Contudo, é interessante tecer alguns comentários sobre a cópia física. Por exemplo, 
não há nenhum valor em fazer backup de blocos de disco não utilizados. Se o programa de 
cópia puder acessar a estrutura de dados do bloco livre, poderá evitar a cópia de blocos não 
utilizados. Entretanto, pular blocos não utilizados exige gravar o número de cada bloco na 
frente do bloco (ou o equivalente), pois não é mais verdade que o bloco k na fita seja o bloco 
k no disco. 

Uma segunda preocupação é a cópia de blocos defeituosos. Se todos os blocos defeituo- 
sos forem remapeados pela controladora de disco e ocultos do sistema operacional, conforme 
descreveremos na Seção 5.4.4, a cópia funcionará bem. Por outro lado, se eles forem visíveis 
para o sistema operacional e mantidos em um ou mais “arquivos de blocos danificados” ou 
mapas de bits, será absolutamente fundamental que o programa de cópia física tenha acesso 
a essas informações e evite copiá-los, para impedir erros de leitura de disco sem fim durante 
o processo de backup. 

As principais vantagens da cópia física são a simplicidade e a grande velocidade (ba- 
sicamente, ele pode ser feito na velocidade do disco). As principais desvantagens são a in- 
capacidade de pular diretórios selecionados, de fazer backups incrementais e de restaurar 
arquivos individuais de acordo com o solicitado. Por esses motivos, a maioria das instalações 
faz cópias lógicas. 

A cópia lógica começa em um ou mais diretórios especificados e copia recursivamente 
todos os arquivos e diretórios lá encontrados que tenham mudado desde alguma data base 
dada (por exemplo, o último backup incremental ou completo). Assim, em uma cópia lógica, 
a fita de backup recebe uma série de diretórios e arquivos cuidadosamente identificados, o 
que facilita restaurar um arquivo ou diretório específico mediante solicitação. 

Para poder restaurar corretamente mesmo um único arquivo, todas as informações neces- 
sárias para recriar o caminho até esse arquivo devem ser salvas na mídia de backup. Assim, o 
primeiro passo de uma cópia lógica é fazer uma análise da árvore de diretórios. Obviamente, 
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precisamos salvar todo arquivo ou diretório que tenha sido modificado. Mas para uma restau- 
ração correta, devem ser salvos todos os diretórios (mesmo os não modificados) que ficam no 
caminho para um arquivo ou diretório modificado. Isso significa salvar não apenas os dados 
(nomes de arquivo e ponteiros para i-nodes), mas todos os atributos dos diretórios devem ser 
salvos, para que eles possam ser restaurados com as permissões originais. Os diretórios e seus 
atributos são gravados na fita primeiro e, depois, são salvos os arquivos modificados (com seus 
atributos). Isso torna possível restaurar os arquivos e diretórios em um sistema de arquivos 
novo, em um computador diferente. Desse modo, os programas de backup e restauração po- 
dem ser usados para transportar sistemas de arquivos inteiros entre computadores. 

Um segundo motivo para copiar diretórios não modificados que estão acima dos arqui- 
vos modificados é tornar possível restaurar um único arquivo por incrementos (possivelmente 
para tratar da recuperação de uma exclusão acidental). Suponha que um backup completo 
do sistema de arquivos seja feito na segunda-feira, ao anoitecer. Na terça-feira, o diretório 
/usr/jhs/proj/nr3/ é removido, junto com todos os diretórios e arquivos que estão abaixo dele. 
Na quarta-feira de manhã cedo, um usuário quer restaurar o arquivo /usr/jhs/proj/nr3/plans/ 
summary. Entretanto, não é possível simplesmente restaurar o arquivo summary, pois não há 
lugar para colocá-lo. Os diretórios nr3/ e plans/ devem ser restaurados primeiro. Para obter 
seus proprietários, modos, tempos e tudo mais corretos, esses diretórios devem estar presen- 
tes na fita de backup, mesmo que eles próprios não tenham sido modificados desde o backup 
completo anterior. 

Restaurar um sistema de arquivos a partir das fitas de backup é simples. Para começar, 
um sistema de arquivos vazio é criado no disco. Então, o backup completo mais recente é res- 
taurado. Como os diretórios aparecem primeiro na fita, todos eles são restaurados primeiro, 
fornecendo um esqueleto do sistema de arquivos. Em seguida, são restaurados os arquivos em 
si. Então, esse processo é repetido com o primeiro backup incremental feito após o backup 
completo, em seguida com o próximo e assim por diante. 

Embora a cópia lógica seja simples, existem algumas questões complicadas. Por exem- 
plo, como a lista de blocos livres não é um arquivo, ela não é copiada e, portanto, precisa ser 
reconstruída desde o início, depois que todos os backups tiverem sido restaurados. Fazer isso 
sempre é possível, pois o conjunto de blocos livres é apenas o complemento do conjunto de 
blocos contidos em todos os arquivos combinados. 

Outro problema são os vínculos (links). Se um arquivo está vinculado a dois ou mais 
diretórios, é importante que ele seja restaurado apenas uma vez e que todos os diretórios que 
devem apontar para ele façam isso. 

Uma outra questão é o fato de que os arquivos UNIX podem conter lacunas. É le- 
gítimo abrir um arquivo, escrever alguns bytes, realizar um deslocamento e escrever mais 
alguns bytes. Os blocos intermediários não fazem parte do arquivo e não devem ser copiados 
nem restaurados. Fregientemente, os arquivos de core dump têm uma grande lacuna entre o 
segmento de dados e a pilha. Se não for manipulado corretamente, cada arquivo de núcleo 
restaurado preencherá essa área com zeros e, assim, terá o mesmo tamanho do espaço de en- 
dereçamento virtual (por exemplo, o bytes ou, pior ainda, 2“ bytes). 

Finalmente, arquivos especiais, pipes nomeados e coisas assim nunca devem ser copia- 
dos, independente do diretório em que possam ocorrer (eles não precisam estar confinados 
em /dev/). Para obter mais informações sobre backups de sistema de arquivos, consulte Cher- 
venak et al. (1998) e Zwicky (1991). 


Consistência do sistema de arquivos 


Outra área onde a confiabilidade é importante é a consistência do sistema de arquivos. Mui- 
tos sistemas de arquivos lêem blocos, os modificam e escrevem posteriormente. Se o sistema 
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falhar antes que todos os blocos modificados tenham sido escritos, o sistema de arquivos 
poderá ficar em um estado inconsistente. Esse problema será particularmente crítico se al- 
guns dos blocos que não foram escritos são blocos contendo i-nodes, diretórios ou a lista de 
regiões livres. 

Para tratar do problema de sistemas de arquivos inconsistentes, a maioria dos compu- 
tadores tem um programa utilitário que verifica a consistência do sistema de arquivos. Por 
exemplo, o UNIX tem o programa fsck e o Windows tem o programa chkdsk (ou scandisk, 
nas versões anteriores). Esse utilitário pode ser executado quando o sistema for inicializado, 
especialmente após uma falha. A descrição a seguir diz como o programa fsck funciona. O 
programa chkdsk é bastante diferente, pois trabalha em um sistema de arquivos diferente, mas 
o princípio geral de uso da redundância inerente do sistema de arquivos para repará-lo ainda 
é válido. Todos os verificadores de sistema de arquivos conferem cada sistema de arquivos 
(partição de disco) independentemente dos outros. 

Podem ser feitos dois tipos de verificações de consistência: em blocos e em arquivos. 
Para verificar a consistência de bloco, o programa constrói duas tabelas, cada uma contendo 
um contador para cada bloco, inicialmente configurado como 0. Os contadores na primeira 
tabela monitoram quantas vezes cada bloco está presente em um arquivo; os contadores na se- 
gunda tabela registram com que frequência cada bloco está presente na lista de regiões livres 
(ou no mapa de bits de blocos livres). 

Então, o programa lê todos os i-nodes. Começando a partir de um i-node, é possível 
construir uma lista de todos os números de bloco usados no arquivo correspondente. À medi- 
da que cada número de bloco é lido, seu contador na primeira tabela é incrementado. Então, 
o programa examina a lista de regiões livres ou o mapa de bits, para localizar todos os blocos 
que não estão sendo usados. Cada ocorrência de um bloco na lista de regiões livres resulta no 
incremento de seu contador na segunda tabela. 

Se o sistema de arquivos for consistente, cada bloco terá um valor 1 na primeira tabela 
ou na segunda tabela, conforme ilustrado na Figura 5-19(a). Entretanto, como resultado de 
uma falha, as tabelas podem ficar como na Figura 5-19(b), na qual o bloco 2 não ocorre em 
nenhuma das tabelas. Ele constará como um bloco ausente. Embora os blocos ausentes não 
prejudiquem, eles desperdiçam espaço e, portanto, reduzem a capacidade do disco. A solução 
para os blocos ausentes é simples: o verificador de sistema de arquivos apenas os adiciona na 
lista de regiões livres. 

Outra situação que poderia ocorrer é a da Figura 5-19(c). Aqui, vemos um bloco, o de 
número 4, que ocorre duas vezes na lista de regiões livres (duplicatas podem ocorrer apenas 
se a lista de regiões livres for realmente uma lista; com um mapa de bits isso é impossível). A 
solução aqui também é simples: reconstruir a lista de regiões livres. 

A pior coisa que pode acontecer é o mesmo bloco de dados pertencer a dois ou mais 
arquivos simultaneamente, como se vê na Figura 5-19(d), no caso do bloco 5. Se um desses 
arquivos for removido, o bloco 5 será colocado na lista de regiões livres, levando a uma 
situação na qual o mesmo bloco está sendo usado e, ao mesmo tempo, está livre. Se os dois 
arquivos forem removidos, o bloco será colocado na lista de regiões livres duas vezes. 

A ação apropriada do verificador de sistema de arquivos é alocar um bloco livre, copiar 
o conteúdo do bloco 5 nele e inserir a cópia em um dos arquivos. Desse modo, o conteúdo 
das informações dos arquivos não muda (embora, quase certamente, seja truncado), mas pelo 
menos a estrutura do sistema de arquivos se torna consistente. O erro deve ser informado, 
para permitir que o usuário inspecione o dano. 

Além de verificar se cada bloco é contado corretamente, o verificador de sistema de 
arquivos também confere o sistema de diretório. Ele também usa uma tabela de contadores, 
mas eles são por arquivo, em vez de serem por bloco. O verificador começa no diretório- 
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Número do bloco Número do bloco 
012345678 9101112131415 012345678 9101112131415 


tl lol olli il fofofi [1 [1 fofo] iocos em uso [1 [1 fo[1Jo[1[1[1[1 fojof1 [1 [1 Jojo | Biocos em uso 
oloja [olı [ofoofo] |i fofo fo[1 [1] socos ivres [ofofojo[1 fofofoJo[1 |1 fojofo[1 [1 | Biocos ivres 
(b) 


012345678 9101112131415 012345678 9101112131415 


tl lohlol thh holoki [1 JoJo | Biocos em uso [1[1Jo[1Jof2[1]1[1]oJo[1[1 [1 [ojo]Biocos em uso 
oJo[1Joj ojojofof1[1 fojofo[1[1 | Bicos ives - foJo[1 oi [ofoofo] [1 [ojofo [1 [1] Bicos ivres 


(c) (d) 


Figura 5-19 Estado do sistema de arquivos. (a) Consistente. (b) Bloco ausente. (c) Bloco duplicado na 
lista de regiões livres. (d) Bloco de dados duplicado. 


raiz e desce recursivamente na árvore, inspecionando cada diretório presente no sistema de 
arquivos. Para cada arquivo em cada diretório, ele incrementa um contador que registra a uti- 
lização desse arquivo. Lembre-se de que, devido aos vínculos estritos (hard link), um arquivo 
pode aparecer em dois ou mais diretórios. Os vínculos simbólicos não contam e não fazem o 
contador do arquivo de destino ser incrementado. 

Quando tudo isso for feito, ele terá uma lista, indexada pelo número do i-node, infor- 
mando quantos diretórios contêm cada arquivo. Então, ele compara esses números com as 
contagens de vínculo armazenadas nos próprios i-nodes. Essas contagens começam em 1, 
quando um arquivo é criado, e são incrementadas sempre que um vínculo (estrito) é estabele- 
cido no arquivo. Em um sistema de arquivos consistente, as duas contagens devem concordar. 
Entretanto, dois tipos de erros podem ocorrer: a contagem de vínculos no i-node pode ser 
maior ou menor do que uma em relação a outra. 

Se a contagem de vínculos for maior do que o número de entradas de diretório, então, 
mesmo que todos os arquivos sejam removidos dos diretórios, a contagem ainda será dife- 
rente de zero e o i-node não será removido. Esse erro não é grave, mas desperdiça espaço no 
disco com arquivos que não estão em nenhum diretório. Isso deve ser corrigido configurando- 
se a contagem de vínculos no i-node com o valor correto. 

O outro erro é potencialmente catastrófico. Se duas entradas de diretório estão vincula- 
das a um arquivo, mas o i-node diz que existe apenas uma, quando uma das entradas de dire- 
tório for removida, a contagem do i-node irá a zero. Quando uma contagem de i-node chega 
a zero, o sistema de arquivos marca o i-node como não usado e libera todos os seus blocos. 
Essa ação resultará em um dos diretórios agora apontando para um i-node não utilizado, cujos 
blocos podem logo ser atribuídos a outros arquivos. Novamente, a solução é apenas forçar a 
contagem de vínculos no i-node a ser igual ao número real de entradas de diretório. 

Essas duas operações, verificar blocos e verificar diretórios, são frequentemente integra- 
das por motivos de eficiência (isto é, é exigida apenas uma passagem pelos i-nodes). Outras 
verificações também são possíveis. Por exemplo, os diretórios têm um formato definido, com 
números de i-node e nomes em ASCII. Se um número de i-node for maior do que o número 
de i-nodes presentes no disco, o diretório foi danificado. 

Além disso, cada i-node tem um modo, alguns dos quais são válidos, mas estranhos, 
como 0007, que não permite nenhum acesso ao proprietário e seu grupo, mas permite que 
intrusos leiam, escrevam e executem o arquivo. Poderia ser útil pelo menos informar quais são 
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os arquivos que dão mais direitos aos intrusos do que ao seu proprietário. Os diretórios com 
mais de, digamos, 1000 entradas, também são suspeitos. Os arquivos localizados em diretó- 
rios de usuário, mas que pertencem ao superusuário e têm o bit SETUID ativo, são problemas 
de segurança em potencial, pois esses arquivos adquirem os poderes do superusuário quando 
executados por qualquer usuário. Com um pouco de esforço, alguém pode construir uma lista 
razoavelmente longa de situações tecnicamente válidas, mas ainda peculiares, que poderiam 
valer a pena relatar. 

Os parágrafos anteriores discutiram o problema da proteção do usuário contra falhas. 
Alguns sistemas de arquivos também se preocupam em proteger o usuário contra ele mesmo. 
Se o usuário pretende digitar 


rm *.o 


para remover todos os arquivos que terminam com .o (arquivos-objeto gerados pelo compila- 
dor), mas acidentalmente digita 


* 


rm’ .o 


(observe o espaço após o asterisco), rm removerá todos os arquivos do diretório corrente e 
depois reclamará que não consegue encontrar .o. Em alguns sistemas, quando um arquivo 
é removido, tudo que acontece é que um bit é ativado no diretório ou no i-node, marcando 
o arquivo como removido. Nenhum bloco de disco é retornado para a lista de regiões livres 
até que seja realmente necessário. Assim, se o usuário descobrir o erro imediatamente, será 
possível executar um programa utilitário especial que restaura os arquivos removidos. No 
Windows, os arquivos removidos são colocados na lixeira (recycle bin), a partir da qual eles 
podem ser recuperados posteriormente, se for necessário. É claro que nenhum espaço de ar- 
mazenamento é recuperado até que eles sejam realmente excluídos desse diretório. 

Mecanismos como esse são inseguros. Um sistema seguro sobrescreveria realmente os 
blocos de dados com zeros ou bits aleatórios, quando um disco fosse excluído, para que outro 
usuário não pudesse recuperá-lo. Muitos usuários não sabem por quanto tempo os dados po- 
dem sobreviver. Dados confidenciais ou sigilosos freqiientemente podem ser recuperados de 
discos que foram descartados (Garfinkel e Shelat, 2003). 


Desempenho do sistema de arquivos 


O acesso ao disco é muito mais lento do que o acesso à memória. A leitura de uma palavra da 
memória é cerca de 10 ns. A leitura de um disco rígido ocorre em torno de 10 MB/s, o que é 
40 vezes mais lento por palavra de 32 bits, e a isso devem ser somados de 5 a 10 ms para bus- 
car a trilha e, então, esperar que o setor desejado chegue sob o cabeçote de leitura. Se apenas 
uma palavra for necessária, o acesso à memória será da ordem de um milhão de vezes mais 
rápido do que o acesso ao disco. Como resultado dessa diferença no tempo de acesso, muitos 
sistemas de arquivos foram projetados com várias otimizações para melhorar o desempenho. 
Nesta seção, abordaremos três delas. 


Uso de cache 


A técnica mais comum utilizada para reduzir o tempo de acesso ao disco é a cache de blocos 
ou cache de buffer. (Cache é pronunciado como “cáche” e deriva do francês cacher, que 
significa “ocultar”.) Neste contexto, uma cache é um conjunto de blocos logicamente perten- 
centes ao disco, mas que são na memória por motivos de desempenho. 

Vários algoritmos podem ser usados para gerenciar a cache, mas um algoritmo comum 
é verificar as requisições de leitura para verificar se o bloco necessário está na cache. Se es- 
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tiver, a requisição de leitura poderá ser atendida sem acesso ao disco. Se o bloco não estiver 
na cache, ele primeiro é lido na cache e depois copiado onde for necessário. As requisições 
subsegiientes para o mesmo bloco podem ser atendidas a partir da cache. 

O funcionamento da cache está ilustrado na Figura 5-20. Como existem muitos blocos 
na cache (frequentemente, milhares deles), é necessária alguma maneira de determinar rapi- 
damente se determinado bloco está presente. A maneira usual é aplicar uma função de hash 
no endereço do dispositivo e do bloco de disco e pesquisar o resultado em uma tabela hash. 
Todos os blocos com o mesmo valor de hash (isso é denominado de colisão) são concatena- 
dos em uma lista encadeada a qual deve ser percorrida para se encontrar o bloco desejado. 

Tabela hash 


Início (LRU) Fim (MRU) 


Figura 5-20 As estruturas de dados da cache de buffer. 


Quando um bloco precisa ser carregado na cache e ela estiver plena, um bloco deve ser 
removido (e reescrito no disco, caso tenha sido modificado desde que foi trazido da memó- 
ria). Essa situação é muito parecida com a paginação e todos os algoritmos de substituição de 
página normais descritos no Capítulo 4, como FIFO, segunda chance e LRU, são aplicáveis. 
Uma diferença agradável entre paginação e uso de cache é que as referências de cache são 
relativamente raras, de modo que é possível manter todos os blocos na ordem LRU exata, 
com listas encadeadas. 

Na Figura 5-20, vemos que, além da lista encadeada para tratar de colisão, começando 
na tabela hash, existe também uma lista bidirecional percorrendo todos os blocos na ordem de 
utilização, com o bloco menos recentemente usado no início dessa lista e o bloco mais recente- 
mente usado no final. Quando um bloco é referenciado, ele pode ser removido de sua posição 
na lista bidirecional e colocado no final. Desse modo, a ordem LRU exata pode ser mantida. 

Infelizmente, há um problema. Agora que temos uma situação na qual a ordem LRU 
exata é possível, verifica-se que o algoritmo LRU é indesejável. O problema está relacionado 
com as falhas e com a consistência do sistema de arquivos, discutida na seção anterior. Se um 
bloco crítico, como um bloco de i-node, for lido na cache e modificado, mas não for reescrito 
no disco, uma falha deixará o sistema de arquivos em um estado inconsistente. Se o bloco 
do i-node for colocado no final do encadeamento LRU, poderá demorar muito para que ele 
alcance o início e seja reescrito no disco. 

Além disso, alguns blocos, como os blocos de i-node, raramente são referenciados duas 
vezes dentro de um curto intervalo de tempo. Essas considerações levam a um esquema LRU 
modificado, considerando dois fatores: 


1. O bloco será utilizado em breve? 


2. O bloco é fundamental para a consistência do sistema de arquivos? 


Para as duas perguntas, os blocos podem ser divididos em categorias como blocos de 
i-node, blocos indiretos, blocos de diretório, blocos de dados completos e blocos de dados 
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parcialmente completos. Os blocos que provavelmente não serão necessários novamente em 
breve ficam no início, em vez de ficarem no fim da lista LRU, para que seus buffers sejam 
reutilizados rapidamente. Os blocos que podem ser utilizados em breve, como um bloco par- 
cialmente completo que está sendo escrito, ficam no fim da lista, para que estejam à mão por 
bastante tempo. 

A segunda questão é independente da primeira. Se o bloco é fundamental para a consis- 
tência do sistema de arquivos (basicamente tudo, exceto os blocos de dados) e foi modificado, 
ele deve ser escrito no disco imediatamente, independente da extremidade da lista LRU em 
que seja colocado. Escrevendo os blocos críticos rapidamente, reduzimos enormemente a 
probabilidade de uma falha destruir o sistema de arquivos. Embora um usuário possa ficar 
descontente se um de seus arquivos for arruinado em uma falha, provavelmente ficará bem 
mais descontente se o sistema de arquivos inteiro for perdido. 

Mesmo com essa medida para manter a integridade do sistema de arquivos intacta, é 
indesejável manter blocos de dados na cache por tempo demais, antes de escrevê-los. Consi- 
dere a situação angustiosa de alguém que esteja usando um computador pessoal para escrever 
um livro. Mesmo que nosso escritor faça o editor salvar periodicamente no disco o arquivo 
que está sendo editado, há uma boa chance de que tudo esteja na cache e nada no disco. Se o 
sistema falhar, a estrutura do sistema de arquivos não será corrompida, mas o trabalho de um 
dia inteiro será perdido. 

Essa situação não precisa acontecer com muita fregiiência, antes que tenhamos um 
usuário completamente infeliz. Os sistemas adotam duas estratégias para tratar disso. A ma- 
neira do UNIX é ter uma chamada de sistema, sync, que obriga todos os blocos modificados 
serem colocados no disco imediatamente. Quando o sistema é inicializado, um programa, 
normalmente chamado de update, é iniciado em segundo plano para ficar em um laço infinito 
executando periodicamente, a cada 30 segundos, chamadas sync. Como resultado, não mais 
do que 30 segundos de trabalho é perdido devido a uma falha do sistema, um pensamento 
reconfortante para muitas pessoas. 

No Windows, cada bloco é gravado no disco assim que ele é modificado. As caches nas 
quais todos os blocos modificados são gravados de volta no disco imediatamente são chama- 
das de caches de escrita direta (write-through). Elas exigem mais operações de E/S de disco 
do que as caches que não são de escrita direta. A diferença entre essas duas estratégias pode 
ser vista quando um programa escreve um bloco de 1 KB completo, um caractere por vez. O 
UNIX reunirá todos os caracteres na cache e escreverá o bloco uma vez a cada 30 segundos 
ou quando o bloco for removido da cache. O Windows fará um acesso ao disco para cada 
caractere escrito. É claro que a maioria dos programas utiliza buffers internos, de modo que, 
normalmente, eles escrevem não um caractere, mas uma linha ou uma unidade maior em cada 
chamada de sistema write. 

Uma conseqiiência dessa diferença na estratégia de uso de cache é que apenas remover 
um disco (disquete) de um sistema UNIX, sem executar uma chamada de sync, quase sempre 
resultará em dados perdidos e, frequentemente, em um sistema de arquivos corrompido tam- 
bém. No Windows, nenhum problema surge. Essas estratégias diferentes foram escolhidas 
porque o UNIX foi desenvolvido em um ambiente no qual todos os discos eram discos rígidos 
e não removíveis, enquanto o Windows começou no mundo dos disquetes. À medida que os 
discos rígidos se tornaram norma, a estratégia do UNIX, com sua melhor eficiência, tornou-se 
a regra, e agora também é usada no Windows para discos rígidos. 


Leitura de bloco antecipada 


Uma segunda técnica para melhorar o desempenho do sistema de arquivos é tentar colocar os 
blocos na cache antes que sejam necessários. Isso para aumentar a taxa de acertos. Em par- 
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ticular, quando o sistema de arquivos é solicitado a acessar o bloco k em um arquivo, ele faz 
isso, mas ao terminar, realiza uma verificação sorrateira na cache para ver se o bloco k + 1 já 
está lá. Se não estiver, ele escalona a leitura do bloco k + 1, na esperança de que, quando for 
necessário, ele já tenha chegado na cache. No mínimo, ele estará a caminho. 

Naturalmente, essa estratégia de leitura antecipada só funciona para arquivos que es- 
tão sendo lidos seqiiencialmente. Se um arquivo estiver sendo acessado aleatoriamente, a 
leitura antecipada não ajudará. Na verdade, é prejudicial ocupar largura de banda do disco 
lendo blocos inúteis e removendo blocos potencialmente úteis da cache (e, possivelmente, 
ocupando mais largura de banda do disco em sua escrita de volta no disco, caso tenham sido 
modificados). Para ver se vale a pena fazer a leitura antecipada, o sistema de arquivos pode 
monitorar os padrões de acesso a cada arquivo aberto. Por exemplo, um bit associado a cada 
arquivo pode monitorar se o arquivo está no “modo de acesso sequencial” ou no “modo de 
acesso aleatório”. Inicialmente, o arquivo recebe o benefício da dúvida e é colocado no modo 
de acesso sequencial. Entretanto, quando é feita uma busca, o bit é zerado. Se leituras segiien- 
ciais começarem a acontecer novamente, o bit será ativado outra vez. Desse modo, o sistema 
de arquivos pode fazer uma estimativa razoável sobre o fato de fazer a leitura antecipada ou 
não. Se ele errar de vez em quando, isso não será um desastre, mas apenas um pequeno des- 
perdício de largura de banda do disco. 


Reduzindo o movimento do braço do disco 


O uso de cache e a leitura antecipada não são as únicas maneiras de aumentar o desempe- 
nho do sistema de arquivos. Outra técnica importante é reduzir a quantidade de movimento 
do braço do disco, colocando os blocos que provavelmente serão acessados em segiiência 
próximos uns dos outros, preferivelmente no mesmo cilindro. Quando um arquivo de saída é 
escrito, o sistema de arquivos precisa alocar os blocos, um por vez, conforme forem necessá- 
rios. Se os blocos livres forem dados por um mapa de bits e o mapa de bits inteiro estiver na 
memória principal, será muito fácil escolher um bloco livre o mais próximo possível do bloco 
anterior. Com uma lista de regiões livres, parte da qual está no disco, é muito mais difícil 
alocar blocos que estejam próximos. 

Entretanto, mesmo com uma lista de regiões livres, algum agrupamento de blocos pode 
ser feito. O truque é monitorar o armazenamento de disco não em blocos, mas em grupos de 
blocos consecutivos. Se os setores consistem em 512 bytes, o sistema pode usar blocos de 
1 KB (2 setores), mas alocar armazenamento em disco em unidades de 2 blocos (4 setores). 
Isso não é o mesmo que ter blocos de disco de 2 KB, pois a cache ainda usaria blocos de 1 
KB e as transferências de disco ainda seriam de 1 KB, mas ler um arquivo segiiencialmente 
em um sistema que, de outro modo, estaria ocioso, reduziria o número de buscas por um fator 
de dois, melhorando consideravelmente o desempenho. Uma variação sobre o mesmo tema 
é levar em conta o posicionamento rotacional. Ao alocar blocos, o sistema tenta colocar os 
blocos consecutivos em um arquivo no mesmo cilindro. 

Outro gargalo de desempenho nos sistemas que usam i-nodes, ou algo equivalente a eles, 
é que a leitura, mesmo de um arquivo pequeno, exige dois acessos ao disco: um para o i-node 
e outro para o bloco. A disposição normal do i-node aparece na Figura 5-21(a). Aqui, todos os 
i-nodes estão próximos ao início do disco; portanto, a distância média entre um i-node e seus 
blocos será cerca de metade do número de cilindros, exigindo buscas longas. 

Uma melhora no desempenho fácil de obter é colocar os i-nodes no meio do disco, em 
vez de colocar no início, reduzindo assim o tempo de busca médio entre o i-node e o primeiro 
bloco por um fator de dois. Outra idéia, mostrada na Figura 5-21(b), é dividir o disco em gru- 
pos de cilindros, cada um com seus próprios i-nodes, blocos e lista de regiões livres (McKusi- 
ck et al., 1984). Ao se criar um novo arquivo, qualquer i-node pode ser escolhido, mas é feita 
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Os i-nodes O disco é dividido em grupos 
estão localizados de cilindros, cada um com 
próximo ao início seus próprios i-nodes 


do disco 


Grupo de cilindros 


(a) (b) 


Figura 5-21 (a) I-nodes armazenados no início do disco. (b) Disco dividido em grupos de 
cilindros, cada um com seus próprios blocos e i-nodes. 


uma tentativa de encontrar um bloco no mesmo grupo de cilindros do i-node. Se não houver 
nenhum disponível, então será usado um bloco em um grupo de cilindros próximo. 


Sistemas de arquivos estruturados em log 


As mudanças na tecnologia estão pressionando os sistemas de arquivos atuais. Em particular, 
as CPUs estão ficando mais rápidas, os discos estão se tornando muito maiores e mais bara- 
tos (mas não muito mais rápidos) e as memórias estão crescendo exponencialmente. O único 
parâmetro que não está melhorando bruscamente é o tempo de busca no disco. A combinação 
desses fatores significa que um gargalo de desempenho está surgindo em muitos sistemas de 
arquivos. Uma pesquisa realizada em Berkeley tentou atenuar esse problema projetando um 
tipo de sistema de arquivos completamente novo, o LFS (Log-structured File System — siste- 
ma de arquivos estruturado em log). Nesta seção, descreveremos sucintamente o funcionamen- 
to do LFS. Para um tratamento mais completo, consulte Rosenblum e Ousterhout (1991). 

A idéia que guiou o projeto do LFS é que, à medida que as CPUs ficam mais rápidas e 
as memórias RAM ficam maiores, as caches de disco também estão aumentando rapidamen- 
te. Conseqiuentemente, agora é possível atender uma fração significativa de todas as requi- 
sições de leitura diretamente a partir da cache do sistema de arquivos, sem necessidade de 
nenhum acesso ao disco. A partir dessa observação, conclui-se que, no futuro, a maior parte 
dos acessos ao disco será para escritas, de modo que o mecanismo de leitura antecipada usado 
em alguns sistemas de arquivos, para buscar blocos antes que sejam necessários, não produz 
mais muitos ganhos no desempenho. 

Para piorar as coisas, na maioria dos sistemas de arquivos as escritas são feitas em tre- 
chos muito pequenos. Escritas de um volume pequeno de dados são altamente ineficientes, 
pois uma escrita em disco equivalente a 50 us é frequentemente precedida por uma busca de 
10 ms e de um atraso rotacional de 4 ms. Com esses parâmetros, a eficiência do disco cai para 
uma fração de 1%. 

Para ver de onde vêm todas as pequenas escritas, considere a criação de um novo ar- 
quivo em um sistema UNIX. Para escrever esse arquivo, o i-node do diretório, o bloco do 
diretório, o i-node do arquivo e o arquivo em si devem ser todos modificados. Embora essas 
escritas possam ser retardadas, fazer isso expõe o sistema de arquivos a sérios problemas de 
consistência, caso ocorra uma falha antes que a escrita seja realizada. Por isso, as escritas de 
i-node geralmente são feitas imediatamente. 
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A partir desse raciocínio, os projetistas do LFS decidiram reimplementar o sistema de 
arquivos do UNIX de maneira a obter a largura de banda total do disco, mesmo perante uma 
carga de trabalho consistindo em grande parte de pequenas escritas aleatórias. A idéia básica 
é estruturar o disco inteiro como um log. Periodicamente (e também quando há necessidade 
especial disso), todas as escritas pendentes que estão sendo colocadas em buffer na memória 
são reunidas em um único segmento e escritas no disco como um único segmento adjacente 
no final do log. Assim, um único segmento pode conter i-nodes, blocos de diretório, blocos de 
dados e outros tipos de blocos, tudo misturado. No início de cada segmento existe um resu- 
mo, informando o que pode ser encontrado no segmento. Se o segmento médio puder ser de 
cerca de 1 MB, praticamente toda largura de banda do disco poderá ser utilizada. 

Nesse projeto, os i-nodes ainda existem e têm a mesma estrutura que no UNIX, mas 
agora eles estão espalhados por todo o log, em vez de estarem em uma posição fixa no disco. 
Contudo, quando um i-node é encontrado, a localização dos blocos é feita da maneira normal. 
É claro que, agora, encontrar um i-node é muito mais difícil, pois seu endereço não pode ser 
simplesmente calculado a partir de seu número de i-node, como acontece no UNIX. Para tor- 
nar possível encontrar os i-nodes, é mantido um mapa de i-nodes, indexado pelo número do 
i-node. A entrada i nesse mapa aponta para o i-node i no disco. O mapa é mantido no disco, 
mas também é colocado na cache, de modo que as partes mais usadas estarão na memória na 
maior parte do tempo, para melhorar o desempenho. 

Para resumirmos o que dissemos até aqui, todas as escritas são inicialmente colocadas 
em buffer na memória e, periodicamente, todas as informações postas no buffer são escritas 
no disco, em um único segmento, no final do log. Agora, a abertura de um arquivo consiste 
em usar o mapa para localizar o i-node do arquivo. Uma vez localizado o i-node, os endereços 
dos blocos podem ser encontrados a partir dele. Todos os blocos estarão, eles próprios, em 
segmentos, em algum lugar no log. 

Se os discos fossem infinitamente grandes, a descrição anterior seria a história toda. 
Entretanto, os discos reais são finitos; portanto, o log crescerá até ocupar o disco inteiro, no 
momento em que mais nenhum segmento novo poderá ser escrito no log. Felizmente, muitos 
segmentos existentes podem ter blocos que não são mais necessários; por exemplo, se um 
arquivo for sobrescrito, seu i-node apontará agora para os novos blocos, mas os antigos ainda 
estarão ocupando espaço nos segmentos escritos anteriormente. 

Para tratar desse problema, o LFS tem uma thread limpadora (cleaner) que passa o 
tempo percorrendo o log de maneira circular para compactá-lo. Ela começa lendo o resumo do 
primeiro segmento no log para ver quais i-nodes e arquivos estão presentes. Então, ela verifica 
o mapa de i-nodes corrente para ver se os i-nodes ainda estão atualizados e se os blocos de 
arquivo ainda estão sendo usados. Se não estiverem, essas informações serão descartadas. Os 
i-nodes e os blocos que ainda estão sendo usados vão para a memória para serem escritos no 
próximo segmento. Então, o segmento original é marcado como livre para que o log possa usá- 
lo para novos dados. Desse modo, a thread limpadora percorre o log, removendo os segmentos 
antigos do final e colocando os dados ativos na memória para reescrever no próximo segmento. 
Consegiientemente, o disco é um grande buffer circular, com uma thread escritora adicionando 
novos segmentos no início e com a thread limpadora removendo os antigos do final. 

A contabilidade aqui não é simples, pois quando um bloco de arquivo é escrito de volta 
em um novo segmento, o i-node do arquivo (em algum lugar no log) deve ser localizado, 
atualizado e colocado na memória para ser escrito no próximo segmento. Então, o mapa 
de i-nodes deve ser atualizado para apontar para a nova cópia. Contudo, é possível fazer a 
administração e os resultados no desempenho mostram que toda essa complexidade vale a 
pena. Medidas feitas nos artigos citados anteriormente mostram que o LFS supera em muito o 
UNIX para escritas de pequeno volume de dados, ao passo que tem um desempenho tão bom 
ou melhor do que o UNIX para leituras e escritas de grande quantidade de dados. 
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5.4 SEGURANÇA 


5.4.1 


Os sistemas de arquivos geralmente contêm informações altamente valiosas para seus usuá- 
rios. Portanto, proteger essas informações contra uso não autorizado é uma preocupação im- 
portante em todos os sistemas de arquivos. Nas seções a seguir, veremos uma variedade de 
questões relacionadas com segurança e proteção. Essas questões se aplicam igualmente bem 
aos sistemas de compartilhamento de tempo, bem como às redes de computadores pessoais 
conectados em servidores compartilhados por meio de redes locais. 


O ambiente de segurança 


As pessoas freqiientemente usam os termos “segurança” e “proteção” indistintamente. Con- 
tudo, muitas vezes é útil fazer uma distinção entre os problemas gerais envolvidos na garantia 
de que os arquivos não sejam lidos nem modificados por pessoas não autorizadas, o que por 
um lado inclui questões técnicas, administrativas, jurídicas e políticas, e por outro, os meca- 
nismos específicos do sistema operacional usados para proporcionar segurança. Para evitar 
confusão, usaremos o termo segurança quando nos referirmos ao problema geral e o termo 
mecanismos de proteção para nos referirmos aos elementos específicos do sistema operacio- 
nal usados para proteger as informações no computador. Entretanto, o limite entre eles não é 
bem definido. Primeiramente, veremos a segurança para saber qual é a natureza do problema. 
Posteriormente neste capítulo, veremos os mecanismos de proteção e os modelos disponíveis 
para ajudar a obter segurança. 

A segurança tem muitas facetas. Três das mais importantes são a natureza das ameaças, a 
natureza dos intrusos e a perda acidental de dados. Veremos agora cada uma delas por sua vez. 


Ameaças 


Da perspectiva da segurança, os sistemas de computador têm três objetivos gerais, com 
ameaças correspondentes a eles, conforme listado na Figura 5-22. O primeiro deles, o cará- 
ter confidencial dos dados, está relacionado com o fato de manter dados sigilosos em segre- 
do. Mais especificamente, se o proprietário de alguns dados tiver decidido que eles só devem 
se tornar disponíveis para certas pessoas e não para outras, o sistema deve garantir que não 
ocorra a liberação dos dados para pessoas não autorizadas. No mínimo, o proprietário deve 
ser capaz de especificar quem pode ver o que e o sistema deve impor essas especificações. 

O segundo objetivo, a integridade dos dados, significa que usuários não autorizados 
não devem ser capazes de modificar quaisquer dados sem a permissão do proprietário. Nesse 
contexto, a modificação dos dados inclui não apenas alterá-los, mas também remover dados 
e adicionar dados falsos. Se um sistema não pode garantir que os dados nele depositados per- 
maneçam inalterados até que o proprietário decida alterá-los, ele não serve como sistema de 
informações. A integridade normalmente é mais importante do que o caráter confidencial. 


Objetivo Ameaça 
Confidencialidade dos dados Exposição dos dados 
Integridade dos dados Falsificação de dados 
Disponibilidade do sistema Negação de serviço 


Figura 5-22 Objetivos da segurança e ameaças. 


O terceiro objetivo, disponibilidade do sistema, significa que ninguém deve ser capaz 
de perturbar o sistema para torná-lo inútil. Esses ataques de negação de serviço (denial of 
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service) são cada vez mais comuns. Por exemplo, se um computador é um servidor de In- 
ternet, enviar uma avalanche de requisições para ele pode incapacitá-lo, consumindo todo 
seu tempo de CPU apenas para examinar e descartar as requisições recebidas. Se demora, 
digamos, 100 us para processar uma requisição recebida para ler uma página web, então 
alguém que consiga enviar 10.000 requisições/s poderá saturar o computador. Estão disponí- 
veis modelos e tecnologia razoáveis para lidar com ataques sobre o caráter confidencialidade 
e a integridade; frustrar ataques de negação de serviços é muito mais difícil. 

Outro aspecto do problema da segurança é a privacidade: proteger os indivíduos contra 
o uso impróprio das informações sobre eles. Isso leva rapidamente a muitas questões jurídicas 
e morais. O governo deve manter dossiês sobre todo mundo para capturar fraudadores de X, 
onde X pode ser “bem-estar” ou “imposto”, dependendo de sua política? A polícia deve ser 
capaz de pesquisar tudo sobre alguém para impedir o crime organizado? Os funcionários e 
companhias de seguro têm direitos? O que acontece quando esses direitos entram em conflito 
com os direitos individuais? Todas essas perguntas são extremamente importantes, mas estão 
fora dos objetivos deste livro. 


Intrusos 


A maioria das pessoas é correta e obedece a lei; então, por que se preocupar com a seguran- 
ça? Porque, infelizmente, existem algumas pessoas que não são tão corretas e querem causar 
problemas (possivelmente para seu próprio ganho comercial). Na literatura sobre segurança, 
as pessoas que metem o nariz onde não são chamadas estão sendo chamadas de intrusos ou, 
às vezes, de adversários. Os intrusos agem de duas maneiras diferentes. Os intrusos passivos 
querem apenas ler arquivos que não estão autorizados a ler. Os intrusos ativos são mais noci- 
vos; eles querem fazer alterações não autorizadas. Ao se projetar um sistema para ser seguro 
contra intrusos, é importante ter em mente o tipo de intruso contra o qual está sendo feita a 
proteção. Algumas categorias comuns são: 


1. Intromissão casual feita por usuários que não são técnicos. Muitas pessoas pos- 
suem em suas mesas computadores pessoais conectados a um servidor de arqui- 
vos compartilhado e, sendo a natureza humana como ela é, algumas delas lerão 
o correio eletrônico e outros arquivos de outras pessoas, se nenhuma barreira for 
colocada no caminho. A maioria dos sistemas UNIX, por exemplo, tem o padrão 
de que todos os arquivos recentemente criados são legíveis publicamente. 


2. Espionagem feita por pessoal interno. Estudantes, desenvolvedores de sistema, 
operadores e outro pessoal técnico muitas vezes consideram como um desafio pes- 
soal violar a segurança do sistema de computador local. Frequentemente, eles são 
altamente capacitados e estão dispostos a dedicar uma quantidade de tempo subs- 
tancial nesse esforço. 


3. Tentativas decididas de ganhar dinheiro. Alguns programadores de instituições 
bancárias têm tentado roubar o banco para os quais trabalham. Os esquemas têm 
variado desde alterar o software para truncar (em vez de arredondar) as taxas de 
juros, guardar para si a fração dos centavos, roubar contas não utilizadas há anos, 
até a chantagem (“Pague-me, senão vou destruir todos os registros do banco”). 


4. Espionagem comercial ou militar. Espionagem refere-se a uma tentativa séria e 
financiada de um concorrente, ou outro país, para roubar programas, segredos co- 
merciais, idéias a serem patenteadas, tecnologia, projetos de circuitos integrados, 
planos comerciais etc. Frequentemente, essa tentativa envolve grampos telefônicos 
ou mesmo montar antenas direcionadas para o computador, para captar sua radia- 
ção eletromagnética. 
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Deve ficar claro que tentar impedir um governo hostil de roubar segredos militares é 
muito diferente de tentar impedir alunos de inserir uma “mensagem do dia” engraçada no 
sistema. A quantidade de esforço necessária para a segurança e para a proteção depende cla- 
ramente de quem é o inimigo. 


Programas nocivos (malware) 


Outra categoria de peste contra a segurança são os programas nocivos, às vezes chamados 
de malware. De certo modo, um escritor de malware também é um intruso, fregientemente 
com muitos conhecimentos técnicos. A diferença entre um intruso convencional e o malware 
é que o primeiro se refere a alguém que está pessoalmente tentando invadir um sistema para 
causar danos, enquanto o último é um programa escrito por essa pessoa e depois lançado para 
o mundo. Alguns programas de malware parecem ter sido escritos apenas para causar danos, 
mas alguns têm um objetivo mais específico. Isso está se tornando um problema sério e muito 
se tem escrito a respeito (Aycock e Barker, 2005; Cerf, 2005; Ledin, 2005; McHugh e Deek, 
2005; Treese, 2004; e Weiss, 2005) 

O tipo de malware mais conhecido é o vírus. Basicamente, um vírus é um código que 
pode se reproduzir anexando uma cópia de si mesmo em outro programa, o que é análogo à 
reprodução do vírus biológico. O vírus pode fazer outras coisas, além de se reproduzir. Por 
exemplo, ele pode digitar uma mensagem, exibir uma imagem na tela, tocar música ou qual- 
quer coisa inofensiva. Infelizmente, ele também pode modificar, destruir ou roubar arquivos 
(enviando-os por e-mail para algum lugar). 

Outra coisa que um vírus pode fazer é inutilizar o computador enquanto o vírus estiver 
em execução. Isso é chamado de ataque de DOS (Denial Of Service — negação de serviço). A 
estratégia normal é consumir recursos como a CPU desenfreadamente, ou encher o disco de 
lixo. Os vírus (e as outras formas de malware a serem descritas) também podem ser usados 
para causar um ataque de DDOS (Distributed Denial Of Service — negação de serviço distri- 
buída). Nesse caso, ao infectar um computador, o vírus não faz nada imediatamente. Em uma 
data e hora predeterminadas, milhares de cópias do vírus em computadores de todo o mundo 
começam a solicitar páginas web ou outros serviços de rede a partir de seu alvo, por exemplo, 
o site web de um partido político ou de uma empresa. Isso pode sobrecarregar o servidor 
pretendido e as redes que o atendem. 

Os programas de malware frequentemente são criados para se obter lucros. Muitos (se 
não a maioria) e-mails indesejados (spams) são retransmitidos para seus destinos finais por 
redes de computadores infectados por vírus ou outras formas de malware. Um computador 
infectado por um programa nocivo assim torna-se um escravo e informa seu status para seu 
mestre em algum lugar na Internet. Então, o mestre envia spam para ser retransmitido a to- 
dos os endereços de e-mail que puderem ser obtidos de catálogos de endereço de e-mail e 
outros arquivos presentes no escravo. Outro tipo de malware para um esquema de obtenção 
de lucros instala um interceptador de teclado (key logger) em um computador infectado. O 
interceptador registra tudo que é digitado no teclado. Não é muito difícil filtrar esses dados e 
extrair informações como combinações de nome de usuário-senha ou números e datas de ex- 
piração de cartões de crédito. Essas informações são então enviadas de volta para um mestre, 
onde podem ser usadas ou vendidas para uso criminoso. 

Ainda relacionado ao vírus temos o verme (worm). Enquanto um vírus é espalhado 
anexando-se em outro programa e executado quando seu programa hospedeiro é executado, 
um verme é um programa independente. Os vermes se espalham usando redes para transmitir 
cópias deles mesmos para outros computadores. Os sistemas Windows sempre tem um dire- 
tório Startup (Iniciar) para cada usuário; qualquer programa presente nessa pasta será execu- 
tado quando o usuário se conectar. Então, tudo que o verme tem de fazer é dar um jeito de se 
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colocar (ou um atalho para si mesmo) no diretório Startup em um sistema remoto. Existem 
outras maneiras, algumas mais difíceis de detectar, de fazer um computador remoto executar 
um arquivo de programa que tenha sido copiado em seu sistema de arquivos. Os efeitos de 
um verme podem ser iguais aos de um vírus. Na verdade, a distinção entre vírus e verme nem 
sempre é clara; alguns programas de malware usam os dois métodos para se espalhar. 

Outra categoria de malware é o cavalo de Tróia (Trojan horse). Trata-se de um pro- 
grama que aparentemente executa uma função válida — talvez um jogo ou uma versão supos- 
tamente “melhorada” de um utilitário. Mas quando o cavalo de Tróia é executado, alguma 
outra função é realizada, talvez ativando um verme ou um vírus ou fazendo uma das coisas 
irritantes que o malware faz. Os efeitos de um cavalo de Tróia provavelmente são sutis e furti- 
vos. Ao contrário dos vermes e dos vírus, os cavalos de Tróia são voluntariamente carregados 
por download pelos usuários, e assim que forem reconhecidos para que servem e a notícia for 
divulgada, um cavalo de Tróia será excluído dos sites de download respeitáveis. 

Outro tipo de malware é a bomba lógica (logical bomb). Esse dispositivo é um código 
escrito por um dos programadores (no momento, empregado) de uma empresa e inserido 
secretamente no sistema operacional de produção. Contanto que o programador o alimente 
com sua senha diariamente, ele não fará nada. Entretanto, se o programador for despedido 
repentinamente e retirado fisicamente do prédio, sem aviso, no dia seguinte a bomba lógica 
não receberá a senha; portanto, ela explodirá. 

A explosão poderia limpar o disco, apagar arquivos aleatoriamente, fazer cuidadosa- 
mente alterações difíceis de detectar em programas importantes ou cifrar arquivos essenciais. 
Neste último caso, a empresa precisará fazer uma escolha difícil entre chamar a polícia (o que 
pode ou não resultar em uma condenção muitos meses depois) ou ceder a essa chantagem e 
recontratar o ex-programador como “consultor”, por um salário astronômico, para corrigir o 
problema (e esperar que ele não plante novas bombas lógicas enquanto faz isso). 

Uma outra forma de malware é o spyware. Normalmente, ele é adquirido na visita a 
um site web. Em sua forma mais simples, o spyware pode ser nada mais do que um cookie. 
Os cookies são pequenos arquivos trocados entre os navegadores e os servidores web. Eles 
têm um propósito legítimo. Um cookie contém algumas informações que permitem o site 
web identificar você. É como o comprovante que você recebe quando deixa uma bicicleta 
para consertar. Quando você volta à loja, sua parte do comprovante combina com o da sua 
bicicleta (e o preço do reparo). As conexões web não são persistentes; portanto, por exemplo, 
se você mostrar interesse em adquirir este livro quando visitar uma livraria on-line, a livraria 
pedirá para que seu navegador aceite um cookie. Quando tiver terminado de navegar e talvez 
tenha escolhido outros livros para comprar, você clica na página onde seu pedido é finalizado. 
Nesse ponto, o servidor web solicita para seu navegador retornar os cookies que armazenou 
na sessão corrente. Ele pode usar as informações presentes neles para gerar a lista de itens 
que você disse que quer comprar. 

Normalmente, os cookies usados para um propósito como esse expiram rapidamen- 
te. Eles são muito úteis e o comércio eletrônico depende deles. Mas alguns sites web usam 
cookies para propósitos que não são tão benignos. Por exemplo, nos sites web, os anúncios são 
frequentemente fornecidos por empresas diferentes do provedor de informações. Os anuncian- 
tes pagam aos proprietários do site web por esse privilégio. Se um cookie for colocado quando 
você visita uma página com informações sobre, digamos, equipamentos de bicicleta e então 
você for para outro site web que vende roupas, a mesma empresa anunciante pode fornecer 
anúncios nessa página e reunir os cookies que você obteve de outros lugares. Assim, você 
pode, repentinamente, encontrar-se vendo anúncios de luvas especiais ou jaquetas especial- 
mente feitas para ciclistas. Dessa maneira, os anunciantes podem reunir muitas informações 
sobre seus interesses; talvez você não queira compartilhar tantas informações a seu respeito. 


CAPÍTULO 5 e SISTEMA DE ARQUIVOS 489 


5.4.2 


O que é pior, existem várias maneiras pelas quais um site web pode carregar por do- 
wnload um código de programa executável em seu computador. A maioria dos navegadores 
aceita plug-ins para adicionar mais funções, como a exibição de novos tipos de arquivos. 
Fregiientemente, os usuários aceitam ofertas de novos plug-ins sem saber muito sobre o que 
eles fazem. Ou então, um usuário pode voluntariamente aceitar uma oferta oferecida com um 
novo cursor para a área de trabalho que parece um gatinho dançando. E um erro em um na- 
vegador web permitir que um site remoto instale um programa indesejado, talvez após atrair 
o usuário para uma página cuidadosamente construída para tirar proveito da vulnerabilidade. 
Sempre que um programa é aceito de outra fonte, voluntariamente ou não, existe o risco de 
ele conter código que cause danos a você. 


Perda acidental de dados 


Além das ameaças causadas por intrusos maldosos, dados valiosos podem ser perdidos por 
acidente. Algumas das causas comuns de perda acidental de dados são: 


1. Ações divinas: incêndios, inundações, terremotos, guerras, tumultos ou ratos roen- 
do fitas ou disquetes. 


2. Erros de hardware ou software: defeitos da CPU, discos ou fitas ilegíveis, erros de 
telecomunicação, erros de programa. 


3. Erros humanos: entrada de dados incorreta, montagem errada de sistemas de ar- 
quivos em fitas ou discos, execução de programa errado, perda de disco ou fita ou 
algum outro erro. 


A maioria pode ser resolvida mantendo-se backups adequados, preferivelmente bem 
longe dos dados originais. Embora a proteção de dados contra perda acidental possa parecer 
mundana comparada à proteção contra intrusos inteligentes, na prática, provavelmente mais 
danos são causados pela primeira do que pela última. 


Ataques genéricos contra a segurança 


Não é fácil encontrar falhas de segurança. A maneira usual de testar a segurança de um sis- 
tema é contratar um grupo de especialistas, conhecidos como equipes de tigres ou equipes 
de invasão, para ver se eles conseguem invadi-lo. Hebbard et al. (1980) tentaram a mesma 
coisa com alunos de graduação. Com o passar dos anos, essas equipes de invasão descobri- 
ram várias áreas nas quais os sistemas provavelmente são fracos. A seguir, listamos alguns 
dos ataques mais comuns que frequentemente são bem-sucedidos. Ao projetar um sistema, 
certifique-se de que ele possa resistir a ataques como esses. 


1. Solicitar páginas da memória, espaço em disco ou fitas e apenas lê-los. Muitos sis- 
temas não os apagam antes de os alocar e eles podem estar repletos de informações 
interessantes gravadas pelo proprietário anterior. 


2. Tentar chamadas de sistema inválidas ou chamadas de sistemas válidas com parâ- 
metros inválidos, ou mesmo chamadas de sistemas válidas com parâmetros váli- 
dos, mas improváveis. Muitos sistemas podem ser facilmente confundidos. 


3. Começar o login e depois pressionar DEL, RUBOUT ou BREAK no meio da se- 
quência de login. Em alguns sistemas, o programa de verificação de senha será 
eliminado e o login considerado bem-sucedido. 

4. Tentar modificar estruturas complexas do sistema operacional mantidas em espaço 
de usuário (se houver). Em alguns sistemas (especialmente em computadores de 
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5.4.3 


grande porte), para abrir um arquivo, o programa constrói uma grande estrutura 
de dados, contendo o nome do arquivo e muitos outros parâmetros, e a passa para 
o sistema. À medida que o arquivo é lido e escrito, às vezes o sistema atualiza a 
própria estrutura. Alterar esses campos pode acabar com a segurança. 


5. Enganar o usuário, escrevendo um programa que exiba “login:” na tela e desapare- 
ça. Muitos usuários irão até o terminal e voluntariamente informarão seus nomes 
e suas senhas de login, que o programa cuidadosamente registrará para seu mestre 
maligno. 


6. Procurar manuais que dizem “Não faça X”. Tentar o máximo de variações de X 
possível. 


7. Convencer um programador de sistema a alterar o sistema para contornar certas 
verificações de segurança vitais para qualquer usuário com seu nome de login. 
Esse ataque é conhecido como porta dos fundos (back door). 


8. Se tudo isso falhar, o invasor pode encontrar a secretária do diretor do centro de 
computação e oferecer-lhe um suborno polpudo. A secretária provavelmente tem 
fácil acesso a todos os tipos de informações interessantes e normalmente ganha 
pouco. Não subestime os problemas causados por funcionários. 


Esses e outros ataques são discutidos por Linde (1975). Muitas outras fontes de infor- 
mação sobre segurança e teste de segurança podem ser encontradas, especialmente na web. 
Um trabalho recente voltado para o Windows é o de Johansson e Riley (2005). 


Princípios de projeto voltados à segurança 


Saltzer e Schroeder (1975) identificaram vários princípios gerais que podem ser usados como 
guia no projeto de sistemas seguros. Um breve resumo de suas idéias (baseadas na experiên- 
cia com o MULTICS) é descrito a seguir. 

Primeiro, o projeto do sistema deve ser público. Supor que o intruso não vai saber como 
o sistema funciona serve apenas para iludir os projetistas. 

Segundo, o padrão deve ser nenhum acesso. Os erros nos quais um acesso legítimo é 
recusado serão relatados muito mais rapidamente do que os erros nos quais um acesso não 
autorizado é permitido. 

Terceiro, verifique a autorização corrente. O sistema não deve verificar a permissão, de- 
terminar que o acesso é permitido e depois guardar essas informações para uso subsequente. 
Muitos sistemas verificam a permissão quando um arquivo é aberto e não depois. Isso signifi- 
ca que um usuário que abra um arquivo e o mantenha aberto por várias semanas continuará a 
ter acesso, mesmo que o proprietário tenha mudado a proteção do arquivo há muito tempo. 

Quarto, conceda a cada processo o mínimo privilégio possível. Se um editor tiver auto- 
rização apenas para acessar o arquivo a ser editado (especificado quando o editor é ativado), 
editores com cavalos de Tróia não poderão causar muitos danos. Este princípio implica em um 
esquema de proteção refinado. Discutiremos esses esquemas posteriormente neste capítulo. 

Quinto, o mecanismo de proteção deve ser simples, uniforme e incorporado nas cama- 
das mais baixas do sistema. Tentar adaptar segurança em um sistema inseguro já existente 
é praticamente impossível. A segurança, assim como a correção, não é uma característica 
complementar. 

Sexto, o esquema escolhido deve ser psicologicamente aceitável. Se os usuários acha- 
rem que proteger seus arquivos dá muito trabalho, eles simplesmente não protegerão. Con- 
tudo, reclamarão espalhafatosamente se algo der errado. Respostas do tipo “A culpa é sua” 
geralmente não serão bem recebidas. 
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5.4.4 Autenticação de usuário 


Muitos esquemas de proteção são baseados na suposição de que o sistema conhece a iden- 
tidade de cada usuário. O problema de identificar os usuários quando eles se conectam é 
chamado de autenticação do usuário. A maioria dos métodos de autenticação é baseada na 
identificação de algo que o usuário conhece, em algo que tem ou em algo que ele é. 


Senhas 


A forma de autenticação mais amplamente usada é exigir que o usuário digite uma senha. 
A proteção por senha é fácil de entender e implementar. No UNIX, ela funciona assim: o 
programa de login pede para que o usuário digite seu nome e sua senha. A senha é cifrada 
imediatamente. Então, o programa de login lê o arquivo de senhas, que é uma série de linhas 
em código ASCII, uma por usuário, até encontrar a linha contendo o nome de login do usuá- 
rio. Se a senha (cifrada) contida nessa linha corresponder à senha cifrada que acabou de ser 
computada, o login será permitido; caso contrário, será recusado. 

A autenticação por senha é fácil de anular. Lemos com freqiiência sobre grupos de 
alunos de faculdade ou mesmo de segundo grau que, com a ajuda de seus leais computadores 
domésticos, têm invadido algum sistema ultra-secreto de uma grande corporação ou de um 
órgão do governo. Quase sempre a invasão consiste em adivinhar uma combinação de nome 
de usuário e senha. 

Embora existam estudos mais recentes (por exemplo, Klein, 1990), o trabalho clássico 
sobre segurança com senhas continua sendo o de Morris e Thompson (1979) sobre sistemas 
UNIX. Eles compilaram uma lista de senhas prováveis: nomes e sobrenomes, nomes de rua, 
nomes de cidade, palavras de um dicionário de tamanho médio (palavras escritas de trás para 
frente também), números de placa de automóvel e segiiências curtas de caracteres aleatórios. 

Então, eles cifraram cada uma delas usando um conhecido algoritmo de criptografia de 
senhas e verificaram se uma das senhas cifradas combinava com as entradas de sua lista. Mais 
de 86% de todas as senhas apareceram na lista. 

Se todas as senhas consistissem em 7 caracteres escolhidos aleatoriamente a partir dos 
95 caracteres ASCII imprimíveis, o espaço de pesquisa seria de 95,0 que dá cerca de 7 x 
10º. À velocidade de 1000 cifragens por segundo, demoraria 2000 anos para construir a lista 
para confrontar com o arquivo de senhas. Além disso, a lista encheria 20 milhões de fitas 
magnéticas. Mesmo exigir que as senhas contenham pelo menos uma letra minúscula, uma 
letra maiúscula, um caractere especial e tenha pelo menos sete caracteres de comprimento, 
seria uma melhora importante em relação às senhas irrestritas escolhidas pelo usuário. 

Mesmo que seja considerado politicamente impossível exigir que os usuários escolham 
senhas razoáveis, Morris e Thompson descreveram uma técnica que torna o próprio ataque 
deles (cifrar um grande número de senhas antecipadamente) quase inútil. A idéia é associar 
a cada senha um número aleatório de n bits. O número aleatório é alterado quando a senha é 
alterada. O número aleatório é armazenado no arquivo de senhas em forma não cifrada, de 
modo que qualquer um pode lê-lo. Em vez de apenas armazenar a senha cifrada no arquivo de 
senhas, primeiramente a senha e o número aleatório são concatenados e depois cifrados em 
conjunto. Esse resultado é armazenado no arquivo de senhas. 

Agora, considere as implicações para um intruso que queira construir uma lista de se- 
nhas prováveis, cifrá-las e salvar os resultados em um arquivo ordenado, f, para que qualquer 
senha cifrada possa ser pesquisada facilmente. Se um intruso suspeitar que Marilyn poderia 
ser uma senha, não será mais suficiente apenas cifrar Marilyn e colocar o resultado em f. Ele 
precisará cifrar 2” strings, como Marilyn0000, Marilyn0001, Marilyn0002 e assim por dian- 
te, e inserir todas elas em f. Essa técnica aumenta o tamanho de f por 2". O UNIX usa esse 
método com n = 12. Isso é conhecido como salgar o arquivo de senhas. Algumas versões do 
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UNIX tornam o próprio arquivo de senhas ilegível, mas fornecem um programa para pesqui- 
sar entradas mediante solicitação, acrescentando apenas um atraso suficiente para reduzir 
significativamente a velocidade da ação de qualquer invasor. 

Embora esse método ofereça proteção contra intrusos que tentem computar previamen- 
te uma lista grande de senhas cifrar, ele pouco faz para proteger um usuário David cuja senha 
também é David. Uma maneira de estimular as pessoas a escolherem senhas melhores é fazer 
com que o computador aconselhe isso. Alguns computadores têm um programa que gera 
palavras sem sentido, aleatórias e fáceis de pronunciar, como fotally, garbungy ou bipitty, 
que podem ser usadas como senhas (preferivelmente com algumas letras maiúsculas e alguns 
caracteres especiais no meio). 

Outros computadores exigem que os usuários mudem suas senhas regularmente, para 
limitar o dano causado se uma senha vazar. A forma mais extrema dessa estratégia é a senha 
usada apenas uma vez (one time password). Quando essas senhas são utilizadas, o usuário 
recebe um catálogo contendo uma lista de senhas. Cada login usa a próxima senha da lista. 
Se um intruso descobrir uma senha, não adiantará nada, pois na próxima vez deverá ser usada 
uma senha diferente. Recomenda-se que o usuário não perca o catálogo de senhas. 

É evidente que, enquanto uma senha está sendo digitada, o computador não deve exibir 
os caracteres para ocultá-los de bisbilhoteiros que estejam próximos ao terminal. O que é 
menos evidente é que as senhas nunca devem ser armazenadas no computador na forma não 
cifrada. Além disso, nem mesmo o gerente do centro de computação deve ter cópias não ci- 
fradas. Manter senhas não cifradas em qualquer lugar é procurar problemas. 

Uma variação da idéia das senhas é fazer com que cada novo usuário receba uma longa 
lista de perguntas e respostas que, então, são armazenadas no computador em forma cifradas. 
As perguntas devem ser escolhidas de modo que o usuário não precise escrevê-las. Em outras 
palavras, devem ser coisas que ninguém esquece. Perguntas típicas são: 


1. Quem é a irmã de Marjorie? 
2. Em que rua ficava sua escola primária? 


3. A professora Woroboff ensinava o quê? 


No login, o computador pergunta uma delas aleatoriamente e verifica a resposta. 

Outra variação é o desafio-resposta (challenge-response). Quando ela é usada, a pes- 
soa escolhe um algoritmo ao se inscrever como usuário, por exemplo x”. Quando o usuário 
se conecta, o computador apresenta um argumento, digamos, 7, no caso em que o usuário 
digita 49. O algoritmo pode ser diferente de manhã e à tarde, em diferentes dias da semana, 
em diferentes terminais etc. 


Identificação física 

Uma estratégia de autorização completamente diferente é verificar se o usuário tem algum 
item, normalmente um cartão de plástico com uma tarja magnética. O cartão é inserido no 
terminal, o qual então verifica de quem é esse cartão. Este método pode ser combinado com 
uma senha, de modo que um usuário só possa se conectar se (1) tiver o cartão e (2) souber a 
senha. Os caixas automáticos de bancos normalmente funcionam assim. 

Uma outra estratégia é medir características físicas que são difíceis de falsificar. Por 
exemplo, uma leitora de impressão digital ou de reconhecimento de voz no terminal poderia 
verificar a identidade do usuário. (A pesquisa será mais rápida se o usuário disser ao com- 
putador quem ele é, em vez de fazer o computador comparar a impressão digital dada com 
a base de dados inteira.) O reconhecimento visual direto ainda não é viável, mas um dia 
poderá ser. 
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Outra técnica é a análise da assinatura. O usuário assina seu nome com uma caneta es- 
pecial conectada ao terminal e o computador a compara com uma amostra conhecida armaze- 
nada on-line. Melhor ainda é comparar, não a assinatura, mas os movimentos da caneta feitos 
enquanto se escreve. Um bom falsificador pode copiar a assinatura, mas não terá a menor 
idéia da ordem exata em que os movimentos foram feitos. 

A análise do comprimento dos dedos é surpreendentemente prática. Quando ela é usa- 
da, cada terminal tem um dispositivo como o da Figura 5-23. O usuário insere sua mão nele e 
o comprimento de cada um de seus dedos é medido e conferido com a base de dados. 


Mola 


Placa de pressão 


Figura 5-23 Um dispositivo para medir o comprimento dos dedos. 


Poderíamos prosseguir com mais exemplos, porém dois ajudarão a tornar claro um pon- 
to importante. Os gatos e outros animais demarcam seu território urinando em seu perímetro. 
Aparentemente, os gatos conseguem identificar uns aos outros dessa maneira. Suponha que 
alguém apareça com um dispositivo minúsculo capaz de fazer a análise instantânea da urina, 
fornecendo assim uma identificação segura. Cada terminal poderia ser equipado com um des- 
ses dispositivos, junto com um aviso discreto dizendo: “Para se conectar, deposite a amostra 
aqui”. Esse sistema poderia ser absolutamente inviolável, mas provavelmente teria um pro- 
blema de aceitação muito sério por parte dos usuários. 

O mesmo poderia ser dito sobre um sistema composto de um percevejo e um pequeno 
espectrógrafo. Seria solicitado para que o usuário pressionasse seu polegar contra o perceve- 
jo, extraindo assim uma gota de sangue para análise espectrográfica. A questão é que qualquer 
esquema de autenticação deve ser psicologicamente aceitável para a comunidade de usuários. 
As medidas do comprimento dos dedos provavelmente não causarão nenhum problema, mas 
mesmo algo não tão intrusivo como armazenar impressões digitais on-line pode ser inaceitá- 
vel para muitas pessoas. 


Contramedidas 


As instalações de computador que levam a segurança realmente a sério — e poucas levam, até 
o dia em que um intruso tiver invadido o sistema e causado danos — frequentemente adotam 
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5.5 


5.5.1 


medidas para tornar a entrada não autorizada muito mais difícil. Por exemplo, cada usuário 
poderia receber permissão para se conectar apenas em um terminal específico e somente du- 
rante certos dias da semana e certas horas do dia. 

Poderia-se fazer com que as linhas telefônicas funcionassem como segue. Qualquer 
pessoa pode discar e se conectar, mas após um login bem-sucedido, o sistema interrompe 
imediatamente a conexão e liga de volta para o usuário em um número previamente definido. 
Essa medida significa que um intruso não poderá simplesmente tentar invadir a partir de qual- 
quer linha telefônica; somente o telefone (de casa) do usuário funcionará. Em qualquer caso, 
com ou sem retorno de chamada, o sistema deve levar pelo menos 10 segundos para verificar 
qualquer senha digitada em uma linha discada e deve aumentar esse tempo após várias tenta- 
tivas de login malsucedidas consecutivas, para reduzir a velocidade de tentativas dos intrusos. 
Após três tentativas de login malsucedidas, a linha deverá ser desconectada por 10 minutos e 
o pessoal da segurança notificado. 

Todos os logins devem ser registrados. Quando um usuário se conecta, o sistema deve 
informar a hora e o terminal do login anterior, para que ele possa detectar possíveis invasões. 

O próximo passo é colocar armadilhas com iscas para capturar intrusos. Um esquema sim- 
ples é ter um nome de login especial com uma senha fácil (por exemplo, nome de login: guest, 
senha: guest). Quando alguém se conecta usando esse nome, os especialistas em segurança do 
sistema são notificados imediatamente. Outras armadilhas podem ser erros fáceis de encontrar 
no sistema operacional e coisas semelhantes, projetadas com a intenção de pegar intrusos no 
ato. Stoll (1989) escreveu um divertido relato sobre as armadilhas que montou para rastrear um 
espião que invadiu um computador de uma universidade, procurando segredos militares. 


MECANISMOS DE PROTEÇÃO 


Nas seções anteriores, vimos muitos problemas em potencial, alguns deles técnicos, alguns, 
não. Nas seções a seguir, nos concentraremos em algumas das maneiras técnicas detalhadas 
que são usadas nos sistemas operacionais para proteger arquivos e outras coisas. Todas essas 
técnicas fazem uma distinção clara entre política (os dados de quem devem ser protegidos de 
quem) e mecanismo (como o sistema impõe a política). A separação entre política e mecanis- 
mo é discutida por Sandhu (1993). Nossa ênfase serão os mecanismos e não as políticas. 

Em alguns sistemas, a proteção é imposta por um programa chamado monitor de re- 
ferência. Sempre que é tentado o acesso a um recurso possivelmente protegido, o sistema 
primeiro pede ao monitor de referência para verificar sua legalidade. Então, o monitor de 
referência examina suas tabelas de política e toma uma decisão. A seguir, descreveremos o 
ambiente no qual um monitor de referência opera. 


Domínios de proteção 


Um sistema de computador contém muitos objetos (recursos) que precisam ser protegidos. Es- 
ses objetos podem ser hardware (por exemplo, CPUs, áreas de memória, unidades de disco ou 
impressoras) ou software (por exemplo, processos, arquivos, bancos de dados ou semáforos). 

Cada objeto tem um nome exclusivo por meio do qual é referenciado e um conjunto 
finito de operações que os processos podem executar nele. As operações read e write são 
apropriadas para um arquivo; up e down fazem sentido em um semáforo. 

É óbvio que é necessário uma maneira de proibir que os processos acessem objetos que 
não estão autorizados a acessar. Além disso, esse mecanismo também deve tornar possível 
restringir os processos a um subconjunto das operações válidas, quando isso for necessário. 
Por exemplo, o processo A pode ser autorizado a ler o arquivo F, mas não a escrever. 
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Para discutirmos os diferentes mecanismos de proteção, é útil apresentar o conceito 
de domínio. Um domínio é um conjunto de pares (objeto, direitos). Cada par especifica um 
objeto e algum subconjunto das operações que podem ser efetuadas nele. Neste contexto, 
direito significa permissão para executar uma das operações. Frequentemente, um domínio 
corresponde a um único usuário, indicando o que ele pode ou não fazer, mas um domínio 
também pode ser mais geral do que apenas um usuário. 

A Figura 5-24 ilustra três domínios, mostrando os objetos em cada domínio e os direitos 
(Read, Write, eXecute) disponíveis em cada objeto. Note que Impressoral está em dois do- 
mínios ao mesmo tempo. Embora não apareça neste exemplo, é possível que o mesmo objeto 
esteja em vários domínios, com direitos diferentes em cada um. 


Domínio 1 Domínio 2 Domínio 3 


Arquivo1[R] ArquivoS[R] 
Arquivo4[RWX] 


Arquivo5[RW] 


Arquivo6[RWX] 


Impressora1[W] 


Arquivo2[RW] Plotter2[W] 


Figura 5-24 Três domínios de proteção. 


A todo instante, cada processo é executado em algum domínio de proteção. Em outras 
palavras, existe um conjunto de objetos que ele pode acessar e, para cada objeto, ele tem um 
conjunto de direitos. Durante a execução, os processos também podem trocar de um domínio 
para outro. As regras da troca de domínio são altamente dependentes do sistema. 

Para tornarmos a idéia do domínio de proteção mais concreta, vamos ver o UNIX. No 
UNIX, o domínio de um processo é definido por seu UID e seu GID. Dada qualquer com- 
binação de (UID, GID), é possível fazer uma lista completa de todos os objetos (arquivos, 
incluindo dispositivos de E/S representados por arquivos especiais etc.) que podem ser aces- 
sados e se eles podem ser acessados para leitura, escrita ou execução. Dois processos com a 
mesma combinação de (UID, GID) terão acesso a exatamente o mesmo conjunto de objetos. 
Os processos com valores de (UID, GID) diferentes terão acesso a um conjunto de arquivos 
diferente, embora possa haver uma sobreposição considerável na maioria dos casos. 

Além disso, cada processo no UNIX tem duas metades: a parte do usuário e a parte do 
núcleo. Quando o processo faz uma chamada de sistema, ele troca da parte do usuário para 
a parte do núcleo. A parte do núcleo tem acesso a um conjunto de objetos diferente da parte 
do usuário. Por exemplo, o núcleo pode acessar todas as páginas na memória física, o disco 
inteiro e todos os outros recursos protegidos. Assim, uma chamada de sistema causa uma 
troca de domínio. 

Quando um processo executa uma operação exec em um arquivo com o bit SETUID 
ou SETGID ativo, ele adquire um novo UID ou GID efetivo. Com uma combinação de (UID, 
GID) diferente, ele tem um conjunto de arquivos e operações diferentes disponíveis. Executar 
um programa com SETUID ou SETGID também causa uma troca de domínio, pois os direi- 
tos disponíveis mudam. 

Uma questão importante é como o sistema monitora qual objeto pertence a qual domí- 
nio. Pelo menos conceitualmente, pode-se imaginar uma grande matriz, com as linhas sendo 
os domínios e as colunas sendo os objetos. Cada elemento da matriz lista os direitos, se hou- 
ver, que o domínio tem sobre o objeto. A matriz da Figura 5-24 aparece na Figura 5-25. Dada 
essa matriz e o número de domínio corrente, o sistema pode saber se é permitido um acesso a 
determinado objeto, de uma maneira particular, a partir de um domínio especificado. 
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Objeto 
Arquivo! Arquivo2 Arquivo3 Arquivo4 Arquivo5 Arquivo6 Impressoraf Plotter2 


Domínio 
. Leitura 
Leitura r 
2 Leitura Escrita n. Escrita 
Execução Sen 
Leitura 
3 Escrita Escrita Escrita 
Execução 


Figura 5-25 Uma matriz de proteção. 


A troca de domínio em si pode ser facilmente incluída no modelo de matriz, perceben- 
do-se que um domínio é ele próprio um objeto, com a operação enter. A Figura 5-26 mostra a 
matriz da Figura 5-25 novamente, só que agora com os três domínios como objetos. Os pro- 
cessos no domínio 1 podem trocar para o domínio 2, mas, uma vez lá, eles não podem voltar. 
Essa situação modela a execução de um programa SETUID no UNIX. Nenhuma outra troca 
de domínio é permitida neste exemplo. 


Objeto 


Arquivo! Arquivo2 Arquivo3 Arquivo4 Arquivo5 Arquivo6Impressora1 Plotter2 Domínio! Domínio? Domínios 

Domínio 
Leitura 

Escrita 


Leitura Leit 
2 Leitura Escrita Sura Escrita 
Z Escrita 
Leitura 
3 Escrita Escrita Escrita 


Figura 5-26 Uma matriz de proteção com domínios como objetos. 


1 | Leitura 


5.5.2 Listas de controle de acesso 


Na prática, raramente se armazena a matriz da Figura 5-26, pois ela é grande e esparsa. A maio- 
ria dos domínios não tem acesso à maioria dos objetos; portanto, armazenar uma matriz muito 
grande, praticamente vazia, é desperdiçar espaço no disco. Entretanto, dois métodos possíveis 
são armazenar a matriz por linhas ou por colunas e, então, armazenar apenas os elementos que 
não estejam vazios. As duas estratégias são surpreendentemente diferentes. Nesta seção, vere- 
mos o armazenamento por coluna; na próxima, estudaremos o armazenamento por linha. 

A primeira técnica consiste em associar a cada objeto uma lista (ordenada) contendo 
todos os domínios que podem acessar um objeto e como podem acessá-lo. Essa lista é chama- 
da de Lista de Controle de Acesso ou ACL (Access Control List) e está ilustrada na Figura 
5-27. Aqui, vemos três processos, A, Be C, cada um pertencente a um domínio diferente, e 
três arquivos: FI, F2 e F3. Por simplicidade, vamos supor que cada domínio corresponde a 
exatamente um usuário; neste caso, os usuários 4, Be C. Fregiientemente, na literatura sobre 
segurança, os usuários são chamados de sujeitos ou principais, para contrastá-los com as 
coisas possuídas, os objetos, como os arquivos. 

Cada arquivo tem uma ACL associada. O arquivo F7 tem duas entradas em sua ACL 
(separadas por um ponto-e-vírgula). A primeira entrada diz que todo processo pertencente ao 
usuário À pode ler e escrever o arquivo. A segunda entrada diz que todo processo pertencente 
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Proprietário 


Processo 
A Espaço 
de usuário 


JU 


E RENA 


J 


Figura 5-27 Uso de listas de controle de acesso para gerenciar acesso a arquivo. 


ao usuário B pode escrever o arquivo. Todos os outros acessos por parte desses usuários e to- 
dos os acessos por parte de outros usuários são proibidos. Note que os direitos são garantidos 
por usuário e não por processo. No que diz respeito ao sistema de proteção, todo processo 
pertencente ao usuário A pode ler e escrever o arquivo F7. Não importa se há apenas um pro- 
cesso assim ou 100 deles. É o proprietário que importa e não o ID do processo. 

O arquivo F2 tem três entradas em sua ACL: 4, Be € podem todos ler o arquivo e, 
além disso, B também pode escrevê-lo. Nenhum outro acesso é permitido. Aparentemente, o 
arquivo F3 é um programa executável, pois B e C podem ambos lê-lo e executá-lo. B também 
pode escrevê-lo. 

Esse exemplo ilustra a forma mais básica de proteção com ACLs. Na prática, frequen- 
temente são usados sistemas mais sofisticados. Para começo de conversa, mostramos apenas 
três direitos até agora: leitura, escrita e execução. Também pode haver mais direitos. Alguns 
deles podem ser genéricos, isto é, serem aplicados a todos os objetos, e alguns podem ser 
específicos a objetos. Exemplos de direitos genéricos são destruir objeto e copiar objeto. Eles 
poderiam valer para qualquer objeto, independente de seu tipo. Os direitos específicos do 
objeto poderiam incluir anexar mensagem, para um objeto caixa de correio, e classificar em 
ordem alfabética, para um objeto diretório. 

Até aqui, nossas entradas de ACL foram para usuários individuais. Muitos sistemas 
aceitam o conceito de grupo de usuários. Os grupos têm nomes e podem ser incluídos em 
ACLs. São possíveis duas variações sobre a semântica dos grupos. Em alguns sistemas, cada 
processo tem um ID de usuário (UID) e um ID de grupo (GID). Nesses sistemas, uma entrada 
de ACL contém entradas da forma 


UID1, GID1: direitos 1; UID2, GID2: direitos2; ... 


Sob essas condições, quando é feito uma requisição para acessar um objeto, é realizada uma 
verificação usando o UID e o GID do processo que fez a chamada. Se eles estiverem pre- 
sentes na ACL, os direitos listados estarão disponíveis. Se a combinação de (UID, GID) não 
estiver na lista, o acesso não será permitido. 

O uso de grupos dessa maneira introduz efetivamente o conceito de função. Considere 
uma instalação na qual Tana seja administradora de sistema e, portanto, esteja no grupo sysa- 
dm. Entretanto, suponha que a empresa também tenha alguns clubes para funcionários e Tana 
seja membro do clube dos amadores de pomba. Os membros do clube pertencem ao grupo 
pombafan e têm acesso aos computadores da empresa para gerenciar seu banco de dados de 
pombas. Uma parte da ACL poderia ser como se vê na Figura 5-28. 
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Arquivo Lista de controle de acesso 


Senha tana, sysadm: RW 


Pomba dados bill, pombafan: RW; tana, pombafan: RW; .... 


Figura 5-28 Duas listas de controle de acesso. 


Se Tana tentar acessar um desses arquivos, o resultado dependerá do grupo em que ela 
estiver conectada no momento. Quando ela se conecta, o sistema pode pedir para que escolha 
o grupo que vai usar ou podem existir até nomes de login e/ou senhas diferentes para man- 
tê-los separados. O objetivo desse esquema é impedir que Tana acesse o arquivo de senhas 
quando estiver fazendo parte dos amadores de pomba. Ela só pode fazer isso quando estiver 
conectada como administradora do sistema. 

Em alguns casos, um usuário pode ter acesso a certos arquivos independentemente do 
grupo em que esteja conectado no momento. Esse caso pode ser tratado com a introdução de 
curingas (wildcards), os quais significam “todos”. Por exemplo, a entrada 


tana, *: RW 


do arquivo de senhas, daria acesso a Tana independente do grupo em que estivesse no mo- 
mento. 

Uma outra possibilidade é que, se um usuário pertencer a qualquer um dos grupos que 
tenham certos direitos de acesso, o acesso será permitido. Nesse caso, um usuário pertencente 
a vários grupos não precisa especificar o grupo a ser usado no momento do login. Todos eles 
valem o tempo todo. Uma desvantagem dessa estratégia é que ela proporciona menos encap- 
sulamento: Tana pode editar o arquivo de senhas durante uma reunião do clube de amadores 
de pomba. 

O uso de grupos e curingas introduz a possibilidade de bloqueio seletivo de um usuário 
específico no acesso a um arquivo. Por exemplo, a entrada 


virgil, *: (none); *, *: RW 


dá ao mundo todo, exceto a Virgil, acesso de leitura e escrita ao arquivo. Isso funciona porque 
as entradas são percorridas em ordem e a primeira que se aplica é considerada; as entradas 
subseqüentes nem mesmo são examinadas. Uma combinação é encontrada para Virgil na 
primeira entrada e os direitos de acesso, neste caso, (none), são encontrados e aplicados. A 
pesquisa termina nesse ponto. O fato de o resto do mundo ter acesso nunca é visto. 

A outra maneira de tratar com grupos é não ter entradas de ACL consistindo em pares 
(UID, GID), mas fazer com que cada entrada seja um UID ou um GID. Por exemplo, uma 
entrada para o arquivo pomba_dados poderia ser 


debbie: RW; phil: RW; pombafan: RW 


significando que Debbie, Phil e todos os membros do grupo pombafan têm acesso de leitura 
e escrita ao arquivo. 

Às vezes, ocorre de um usuário ou grupo ter certas permissões com relação a um arqui- 
vo, que o proprietário do arquivo posteriormente deseja revogar. Com as listas de controle de 
acesso, é relativamente simples revogar um direito de acesso concedido anteriormente. Basta 
editar a ACL para fazer a alteração. Entretanto, se a ACL for verificada somente quando um 
arquivo for aberto, muito provavelmente a alteração só entrará em vigor nas chamadas futuras 
de open. Qualquer arquivo que já esteja aberto continuará a ter os direitos que tinha quando 
foi aberto, mesmo que o usuário não esteja mais autorizado a acessar o arquivo. 
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5.5.3 Capacidades 


A outra forma de dividir a matriz da Figura 5-26 é por linhas. Quando esse método é usado, 
uma lista dos objetos que podem ser acessados é associada a cada processo, junto com uma 
indicação de quais operações são permitidas em cada um; em outras palavras, seu domínio. 
Essa lista é chamada de lista de capacitação ou lista C e os itens individuais nela presentes 
são chamados de capacidades (Dennis e Van Horn, 1966; Fabry, 1974). Um conjunto de três 
processos e suas respectivas listas de capacitação aparecem na Figura 5-29. 

Cada capacidade garante ao proprietário certos direitos sobre determinado objeto. Na 
Figura 5-29, o processo pertencente ao usuário A pode ler os arquivos F7 e F2, por exemplo. 
Normalmente, uma capacidade consiste em um identificador de arquivo (ou, mais generica- 
mente, de objeto) e um mapa de bits com seus vários direitos. Em um sistema do tipo UNIX, 
o identificador de arquivo provavelmente seria o número do i-node. As próprias listas de 
capacitação são objetos e podem ser apontadas por outras listas de capacitação, facilitando 
assim o compartilhamento de subdomínios. 


Proprietário 
Processo 
N Espaço 
de usuário 
I 
I J 
= 
Espaço 
de núcleo 


Lista C 


J 


Figura 5-29 Quando são usadas capacidades, cada processo tem uma lista de capacitação. 


É bastante óbvio que as listas de capacitação devem ser protegidas contra falsificação 
por parte dos usuários. São conhecidos três métodos de proteção para elas. O primeiro exi- 
ge uma arquitetura etiquetada, ou rotulada (tagged architecture), ou seja, o projeto do 
hardware inclui para cada palavra da memória um bit extra (etiqueta ou rótulo) indicando se 
a palavra contém uma capacidade ou não. O bit de rótulo não é usado por instruções aritmé- 
ticas, de comparação ou instruções normais semelhantes e só pode ser modificado por pro- 
gramas em execução no modo núcleo (isto é, pelo sistema operacional). Foram construídas 
máquinas de arquitetura rotulada e elas funcionavam bem (Feustal, 1972). O AS/400 da IBM 
é um exemplo popular. 

A segunda maneira é manter a lista C dentro do sistema operacional. Então, as ca- 
pacidades são referenciadas por sua posição na lista de capacitação. Um processo poderia 
dizer: “Leia 1 KB do arquivo apontado pela capacidade 2”. Essa forma de endereçamento é 
semelhante ao uso de descritores de arquivo no UNIX. O Hydra funcionava assim (Wulf et 
al., 1974). 

A terceira maneira é manter a lista C no espaço de usuário, mas gerenciar as capaci- 
dades usando técnicas de criptografia para que os usuários não possam falsificá-las. Essa 
estratégia é particularmente conveniente para sistemas distribuídos e funciona como segue. 
Quando um processo cliente envia uma mensagem para um servidor remoto (por exemplo, 
um servidor de arquivos), solicitando a criação de um objeto, o servidor cria o objeto e gera 
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um número aleatório longo, o campo de verificação, para acompanhá-lo. Uma entrada na 
tabela de arquivos do servidor é reservada para o objeto e o campo de verificação é armaze- 
nado lá, junto com os endereços dos blocos de disco etc. Em termos de UNIX, o campo de 
verificação é armazenado no servidor, no i-node. Ele não é enviado de volta para o usuário e 
nunca é colocado na rede. Então, o servidor gera e retorna uma capacidade para o usuário, da 
forma mostrada na Figura 5-30. 


Servidor Objeto Direitos f(Objetos, Direitos, Verificação) 


Figura 5-30 Uma capacidade protegida por criptografia. 


A capacidade retornada para o usuário contém o identificador do servidor, o número do 
objeto (o índice nas tabelas do servidor, basicamente o número do i-node) e os direitos, arma- 
zenados como um mapa de bits. Para um objeto recentemente criado, todos os bits de direito 
são ativados. O último campo consiste na concatenação do objeto, dos seus direitos e de um 
campo de verificação os quais são passados a uma função de cifragem f de sentido único, do 
tipo que discutimos anteriormente. 

Quando o usuário quer acessar o objeto, ele envia a capacidade para o servidor como 
parte da requisição. Então, o servidor extrai o número do objeto para usá-lo como índice 
em suas tabelas para localizar o objeto. Depois, ele calcula (Objeto, Direitos, Verificação), 
extraindo os dois primeiros parâmetros da própria capacidade e o terceiro de suas próprias 
tabelas. Se o resultado concordar com o quarto campo na capacidade, a requisição será aten- 
dida; caso contrário, rejeitada. Se um usuário tentar acessar o objeto de outra pessoa, não 
poderá fabricar o quarto campo corretamente, pois não conhece o campo de verificação, e a 
requisição será rejeitada. 

Um usuário pode solicitar para que o servidor produza e retorne uma capacidade menos 
poderosa, por exemplo, acesso somente para leitura. Primeiro, o servidor verifica se a capa- 
cidade é válida. Se for, ele calcula f (Objeto, Novos direitos, Verificação) e gera uma nova 
capacidade, colocando esse valor no quarto campo. Note que o valor de Verificação original 
é usado, porque outras capacidades a resolver dependem dele. 

Essa nova capacidade é enviada de volta para o processo solicitante. Agora, o usuário 
pode dar isso a um amigo apenas enviando em uma mensagem. Se o amigo ativar os bits de 
direitos que devem estar desativados, o servidor detectará isso quando a capacidade for usada, 
pois o valor de f não corresponderá ao campo de direitos falso. Como o amigo não conhece 
o campo de verificação verdadeiro, ele não pode fabricar uma capacidade que corresponda 
aos bits de direitos falsos. Esse esquema foi desenvolvido para o sistema Amoeba e usado 
extensivamente nele (Tanenbaum et al., 1990). 

Além dos direitos específicos dependentes do objeto, como leitura e execução, as ca- 
pacidades (do núcleo e protegidas por técnicas de criptografia) normalmente têm direitos 
genéricos que são aplicáveis a todos os objetos. Exemplos de direitos genéricos são: 


1. Copiar capacidade: criar uma nova capacidade para o mesmo objeto. 

2. Copiar objeto: criar um objeto duplicado com uma nova capacidade. 

3. Remover capacidade: excluir uma entrada da lista C; não afeta o objeto. 
4. Destruir objeto: remover permanentemente um objeto e uma capacidade. 


Uma última observação importante sobre os sistemas de capacitação é que revogar o 
acesso a um objeto é muito difícil na versão gerenciada pelo núcleo. E difícil para o sistema 
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5.5.4 


encontrar todas as capacidades pendentes de qualquer objeto para tomá-las de volta, pois elas 
podem estar armazenadas em listas C por todo o disco. Uma estratégia é fazer com que cada 
capacidade aponte para um objeto indireto, em vez de apontar para o objeto em si. Fazendo- 
se com que o objeto indireto aponte para o objeto real, o sistema sempre pode desfazer essa 
conexão, invalidando assim as capacidades. (Quando uma capacidade no objeto indireto for 
apresentada posteriormente para o sistema, o usuário descobrirá que o objeto indireto agora 
está apontando para um objeto nulo.) 

No esquema Amoeba, a revogação é fácil. Basta alterar o campo de verificação arma- 
zenado com o objeto. Todas as capacidades existentes são invalidadas de uma só vez. Entre- 
tanto, o esquema não permite revogação seletiva, isto é, pegar de volta, digamos, a permissão 
de John, nem a de mais ninguém. Esse defeito é geralmente reconhecido como sendo um 
problema de todos os sistemas de capacitação. 

Outro problema geral é garantir que o proprietário de uma capacidade válida não for- 
neça uma cópia para 1000 de seus melhores amigos. Fazer com que o núcleo gerencie as 
capacidades, como no Hydra, resolve esse problema, mas essa solução não funciona bem em 
um sistema distribuído como o Amoeba. 

Por outro lado, as capacidades resolvem muito elegantemente o problema do confina- 
mento (sandboxing) de código móvel. Quando um programa estranho é iniciado, ele recebe 
uma lista de capacitação contendo apenas as capacidades que o proprietário da máquina de- 
seja conceder, como a capacidade de escrever na tela e de ler e escrever arquivos em um dire- 
tório de rascunho que acabou de ser criado para ele. Se o código móvel for colocado em seu 
próprio processo, apenas com essas capacidades limitadas, ele não poderá acessar nenhum 
outro recurso do sistema e, assim, ficará efetivamente confinado em uma sandbox, sem neces- 
sidade de modificar seu código nem executá-lo de forma interpretativa. Executar código com 
os mínimos direitos de acesso possíveis é conhecido como princípio do privilégio mínimo e 
é uma diretriz poderosa para produzir sistemas seguros. 

Resumindo, brevemente, as ACLs e as capacidades têm propriedades um tanto com- 
plementares. As capacidades são muito eficientes, pois se um processo diz “Abra o arquivo 
apontado pela capacidade 3”, nenhuma verificação é necessária. Com ACLs, pode ser neces- 
sária uma pesquisa (potencialmente longa) em uma ACL. Se não são suportados grupos, en- 
tão conceder a todo mundo acesso de leitura a um arquivo exigirá enumerar todos os usuários 
na ACL. As capacidades também permitem que um processo seja facilmente encapsulado, 
enquanto as ACLs, não. Por outro lado, as ACLs permitem a revogação seletiva de direitos, 
o que as capacidades não permitem. Finalmente, se um objeto é removido e as capacidades 
não ou se as capacidades são removidas e um objeto não, surgem problemas. As ACLs não 
têm esse problema. 


Canais secretos 


Mesmo com listas de controle de acesso e capacidades, ainda podem ocorrer problemas na 
segurança como o vazamento de informações. Nesta seção, discutiremos como isso pode 
ocorrer mesmo quando tiver sido rigorosamente provado que tal vazamento é matematica- 
mente impossível. Essas idéias devem-se a Lampson (1973). 

O modelo de Lampson foi originalmente formulado em termos de um único sistema de 
compartilhamento de tempo, mas as mesmas idéias podem ser adaptadas para redes locais e 
outros ambientes multiusuário. Na forma mais pura, ele envolve três processos em uma máqui- 
na protegida. O primeiro processo é o cliente, o qual deseja algum trabalho realizado pelo se- 
gundo, o servidor. O cliente e o servidor não confiam inteiramente um no outro. Por exemplo, 
a tarefa do servidor é ajudar os clientes no preenchimento de seus formulários de imposto. Os 
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clientes estão preocupados com o fato de o servidor registrar secretamente seus dados financei- 
ros, como manter uma lista secreta de quem ganha quanto e depois vender a lista. O servidor 
está preocupado com o fato de os clientes tentarem roubar o valioso programa de imposto. 

O terceiro processo é o colaborador, o qual está conspirando com o servidor para roubar 
de fato os dados confidenciais do cliente. O colaborador e o servidor normalmente pertencem 
à mesma pessoa. Esses três processos aparecem na Figura 5-31. O objetivo deste exercício é 
projetar um sistema no qual seja impossível o processo servidor vazar para o processo colabo- 
rador as informações que recebeu legitimamente do processo cliente. Lampson chamou isso 
de problema do confinamento. 


Cliente Servidor Colaborador Servidor encapsulado 


Núcleo Núcleo Canal 


secreto 


(a) (b) 


Figura 5-31 (a) Os processos cliente, servidor e colaborador. (b) O servidor encapsulado 
ainda pode vazar para o colaborador por meio de canais secretos. 


Do ponto de vista do projetista de sistema, o objetivo é encapsular ou confinar o servidor 
de maneira tal que ele não possa passar informações para o colaborador. Usando um esquema 
de matriz de proteção, podemos garantir facilmente que o servidor não possa se comunicar 
com o colaborador escrevendo um arquivo para o qual o colaborador tenha acesso de leitura. 
Provavelmente, também podemos garantir que o servidor não possa se comunicar com o co- 
laborador usando o mecanismo de comunicação entre processos normal do sistema. 

Infelizmente, canais de comunicação mais sutis podem estar disponíveis. Por exemplo, 
o servidor pode tentar comunicar um fluxo de bits binário, como segue: para enviar um bit 1, 
ele computa o máximo que puder, por um intervalo de tempo fixo. Para enviar um bit 0, ele 
entra em repouso pelo mesmo período de tempo. 

O colaborador pode tentar detectar o fluxo de bits monitorando cuidadosamente seu 
tempo de resposta. Em geral, ele obterá melhor resposta quando o servidor estiver enviando 
um O do que quando estiver enviando um 1. Esse canal de comunicação é conhecido como 
canal secreto e está ilustrado na Figura 5-31(b). 

É claro que o canal secreto tem muito ruído, contendo muitas informações estranhas, 
mas informações confiáveis podem ser enviadas por meio de um canal com muito ruído usan- 
do-se um código de correção de erro (por exemplo, um código de Hamming ou mesmo algo 
mais sofisticado). O uso de um código de correção de erro reduz ainda mais a já estreita 
largura de banda do canal secreto, mas ainda pode ser suficiente para vazar informações subs- 
tanciais. É bastante óbvio que nenhum modelo de proteção baseado em uma matriz de objetos 
e domínios consiga evitar esse tipo de vazamento. 

Modular o uso da CPU não é o único canal secreto existente. A taxa de paginação tam- 
bém pode ser modulada (muitas faltas de página para um 1, nenhuma falta de página para 
um 0). Na verdade, praticamente qualquer maneira de degradar o desempenho do sistema de 
maneira cronometrada é uma possibilidade. Se o sistema fornecer uma maneira de bloquear 
arquivos, então o servidor poderá bloquear algum arquivo para indicar um 1 e desbloqueá-lo 
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para indicar um 0. Em alguns sistemas, é possível que um processo detecte o status de um 
bloqueio, mesmo em um arquivo que ele não pode acessar. Esse canal secreto está ilustrado 
na Figura 5-32, com o arquivo bloqueado ou desbloqueado por algum intervalo de tempo 
fixo, conhecido pelo servidor e pelo colaborador. Nesse exemplo, está sendo transmitido o 
fluxo de bits secreto 11010100. 


ITTY 
EER 


O servidor bloqueia O servidor desbloqueia 
o arquivo para B [| o arquivo para 
enviar 1 enviar 0 
1 1 0 1 0 0 o <— Fluxo de bits 
enviado 


Colaborador —» O O O O 


Figura 5-32 Um canal secreto usando bloqueio de arquivo. 


OO 


Bloquear e desbloquear um arquivo previamente preparado cria um canal secreto $ 
que não possui muito ruído de comunicação, mas exige uma cronometragem muito precisa, 
a não ser que a taxa de bits seja muito lenta. A confiabilidade e o desempenho podem ser 
ainda mais aumentados usando-se um protocolo de confirmação. Esse protocolo usa mais 
dois arquivos, F7 e F2, bloqueados pelo servidor e pelo colaborador, respectivamente, para 
manter os dois processos sincronizados. Depois que o servidor bloqueia ou desbloqueia S, 
ele muda rapidamente o status de bloqueio de F7 para indicar que um bit foi enviado. Assim 
que o colaborador tiver lido o bit, ele muda rapidamente o status de bloqueio de F2 para in- 
formar o servidor que está pronto para outro bit e espera até que o status de F7 seja alterado 
rapidamente outra vez, para indicar que outro bit está sendo enviado no canal secreto S. Como 
não há mais cronometragem envolvida, esse protocolo é totalmente confiável, mesmo em um 
sistema com muita carga, e pode prosseguir na mesma rapidez com que os dois processos são 
escalonados para executar. Para obter uma largura de banda mais alta, por que não usar dois 
arquivos por tempo de bit ou torná-lo um canal do tamanho de um byte, com oito arquivos de 
sinalização, de SO a $7? 

Adquirir e liberar recursos dedicados (unidades de fita, plotters etc.) também pode ser 
usado para a sinalizar bits. O servidor adquire o recurso para enviar um 1 e o libera para en- 
viar um 0. No UNIX, o servidor poderia criar um arquivo para indicar um 1 e removê-lo para 
indicar um 0; o colaborador poderia usar a chamada de sistema access para ver se o arquivo 
existe. Essa chamada funciona mesmo que o colaborador não tenha permissão para usar o 
arquivo. Infelizmente, existem muitos outros canais secretos. 

Lampson também menciona uma maneira de vazar informações para o proprietário 
(humano) do processo servidor. Presumivelmente, o processo servidor será autorizado a dizer 
ao seu proprietário quanto trabalho fez em nome do cliente, para que o mesmo possa ser co- 
brado. Se o preço da computação for, digamos, U$100 e o salário do cliente for de U$53.000, 
o servidor poderá informar para seu proprietário a conta como sendo U$100,53. 

Apenas encontrar todos os canais secretos, sem bloqueá-los, é extremamente difícil. Na 
prática, pouco se pode fazer. Introduzir um processo que cause falta de página aleatoriamente 
ou que de alguma forma passe o tempo degradando o desempenho do sistema para reduzir a 
largura de banda dos canais secretos não é uma proposta atraente. 
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5.6 VISÃO GERAL DO SISTEMA DE ARQUIVOS DO MINIX 3 


5.6.1 


Assim como qualquer sistema de arquivos, o sistema de arquivos do MINIX 3 deve tratar de 
todas as questões que acabamos de estudar. Ele deve alocar e liberar espaço para arquivos, 
monitorar blocos de disco e o espaço livre, fornecer alguma maneira de proteger os arquivos 
contra utilização não autorizada etc. No restante deste capítulo, estudaremos detidamente o 
MINIX 3 para vermos como ele atinge esses objetivos. 

Na primeira parte deste capítulo, por questões de generalidade, nos referimos repeti- 
damente ao UNIX, em vez do MINIX 3, embora as interfaces externas dos dois sejam prati- 
camente idênticas. Agora, vamos nos concentrar no projeto interno do MINIX 3. Para obter 
informações sobre os detalhes internos do UNIX, consulte Thompson (1978), Bach (1987), 
Lions (1996) e Vahalia (1996). 

O sistema de arquivos do MINIX 3 é apenas um grande programa em C executado em 
espaço de usuário (veja a Figura 2-29). Para ler e escrever arquivos, os processos de usuário 
enviam mensagens para o sistema de arquivos informando o que querem fazer. O sistema de 
arquivos realiza o trabalho e depois envia de volta uma resposta. Na verdade, o sistema de 
arquivos é um servidor de arquivos de rede que por acaso está sendo executado na mesma 
máquina do processo que fez a chamada. 

Esse projeto tem algumas implicações importantes. Por um lado, o sistema de arquivos 
pode ser modificado, experimentado e testado de forma quase completamente independente 
do restante do MINIX 3. Por outro, é muito fácil mover o sistema de arquivos para qualquer 
computador que tenha um compilador C, compilá-lo lá e usá-lo como um servidor de arqui- 
vos remoto independente, do tipo UNIX. As únicas alterações que precisam ser feitas são o 
modo como as mensagens são enviadas e recebidas, que difere de um sistema para outro. 

Nas seções a seguir, apresentaremos um panorama de muitas áreas importantes do pro- 
jeto do sistema de arquivos. Especificamente, veremos as mensagens, o layout do sistema de 
arquivos, os mapas de bits, os i-nodes, a cache de blocos, os diretórios e caminhos, os des- 
critores de arquivo, o travamento de arquivo e os arquivos especiais (além dos pipes). Após 
estudarmos esses assuntos, mostraremos um exemplo simples de como as partes se encaixam, 
investigando o que acontece quando um processo de usuário executa a chamada de sistema 
read. 


Mensagens 


O sistema de arquivos aceita 39 tipos de mensagens solicitando trabalho. Todas, menos duas, 
são para chamadas de sistema do MINIX 3. As duas exceções são mensagens geradas por 
outras partes do MINIX 3. Das chamadas de sistema, 31 são aceitas a partir de processos 
do usuário. Seis mensagens servem para chamadas de sistema tratadas primeiramente pelo 
gerenciador de processos (PM — Process Manager), as quais então chamam o sistema de 
arquivos para fazer uma parte do trabalho. Duas outras mensagens também são manipuladas 
pelo sistema de arquivos. As mensagens aparecem na Figura 5-33. 

A estrutura do sistema de arquivos é basicamente a mesma do gerenciador de processos 
e de todos os drivers de dispositivo de E/S. Ela tem um laço principal que espera a chegada 
de uma mensagem. Quando chega uma mensagem, seu tipo é extraído e usado como índice 
em uma tabela contendo ponteiros para as funções dentro do sistema de arquivos que as ma- 
nipulam. Então, a função apropriada é chamada, faz seu trabalho e retorna um valor de status. 
O sistema de arquivos envia, então, uma resposta para o processo que fez a chamada e volta 
para o início do laço para esperar a próxima mensagem. 
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Mensagens dos usuários 


Parâmetros de entrada 


Valor da resposta 


access Nome do arquivo, modo de acesso Status 
chdir Nome do novo diretório de trabalho Status 
chmod Nome do arquivo, novo modo Status 
chown Nome do arquivo, novo proprietário, grupo Status 
chroot Nome do novo diretório-raiz Status 
close Descritor do arquivo a fechar Status 
creat Nome do arquivo a ser criado, modo Descritor de arquivo 


dup Descritor de arquivo (para dup2, dois fds) Novo descritor de arquivo 
fcntl Descritor de arquivo, código de função, arg Depende da função 
fstat Nome de arquivo, buffer Status 

ioctl Descritor de arquivo, código de função, arg Status 

link Nome do arquivo a ser vinculado, nome do vínculo Status 

Iseek Descritor de arquivo, deslocamento, de onde Nova posição 

mkdir Nome do arquivo, modo Status 

mknod Nome do dir ou arquivo especial, modo, endereço Status 

mount Arquivo especial, onde montar, flag ro Status 

open Nome do arquivo a abrir, flag r/w Descritor de arquivo 
pipe Ponteiro para 2 descritores de arquivo (modificado) Status 

read Descritor de arquivo, buffer, quantos bytes Número de bytes lidos 
rename Nome do arquivo, nome do arquivo Status 

rmdir Nome do arquivo Status 

stat Nome do arquivo, buffer de status Status 

stime Ponteiro para o tempo corrente Status 

sync (Nenhum) Sempre OK 

time Ponteiro para onde o tempo corrente é armazenado Status 

times Ponteiro para buffer de tempos de processo e filho Status 

umask Complemento da máscara de modo Sempre OK 

umount Nome do arquivo a desmontar Status 

unlink Nome do arquivo a desvincular Status 

utime Nome do arquivo, tempos do arquivo Sempre OK 

write Descritor de arquivo, buffer, quantos bytes Número de bytes escritos 


Mensagens do PM 


Parâmetros de entrada 


Valor da resposta 


exec Pid Status 
exit Pid Status 
fork Pid do pai, pid do filho Status 


setgid Pid, gid real e efetiva Status 
setsid Pid Status 
setuid Pid, uid real e efetiva Status 


Outras mensagens 


Parâmetros de entrada 


Valor da resposta 


revive 


Processo a reanimar 


(Nenhuma resposta) 


unpause 


Processo a verificar 


(Veja o texto) 


Figura 5-33 Mensagens do sistema de arquivos. Os parâmetros de nome de arquivo são sempre pon- 
teiros para o nome. O código status como valor de resposta significa OK ou ERROR. 
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5.6.2 Layout do sistema de arquivos 


O sistema de arquivos do MINIX 3 é uma entidade lógica independente, com i-nodes, diretó- 
rios e blocos de dados. Ele pode ser armazenado em qualquer dispositivo de bloco, como um 
disquete ou uma partição de disco rígido. Em todos os casos, o layout do sistema de arquivos 
tem a mesma estrutura. A Figura 5-34 mostra esse layout para um disquete ou para uma parti- 
ção de disco rígido pequena com 64 i-nodes e um tamanho de bloco de 1 KB. Nesse exemplo 
simples, o mapa de bits de zona é apenas um bloco de 1 KB; portanto, ele não pode monitorar 
mais do que 8192 zonas (blocos) de 1 KB, limitando assim o sistema de arquivos a 8 MB. 
Mesmo para um disquete, apenas 64 i-nodes impõem um sério limite para o número de ar- 
quivos; portanto, em vez dos quatro blocos reservados para i-nodes na figura, provavelmente 
seriam usados mais. Reservar oito blocos para i-nodes seria mais prático, mas nosso diagrama 
não ficaria tão bom. É claro que, para um disco rígido moderno, os mapas de bits de i-node e 
de zona seriam muito maiores do que 1 bloco. O tamanho relativo dos vários componentes na 
Figura 5-34 pode variar de um sistema de arquivos para outro, dependendo de seus tamanhos, 
de quantos arquivos são permitidos no máximo etc. Mas todos os componentes estão sempre 
presentes e na mesma ordem. 


Bloco de 
inicialização Superbloco 
Nós-i Um bloco do disco 
m “~ 


Mapa de bits Mapa de bits 
de i-nodes de zona 


Figura 5-34 Layout de disco para um disquete, ou para uma partição de disco rígido peque- 
na, com 64 i-nodes e um tamanho de bloco de 1 KB (isto é, dois setores consecutivos de 512 
bytes são tratados como um único bloco). 


Cada sistema de arquivos começa com um bloco de inicialização (boot block). Ele 
contém código executável. O tamanho de um bloco de inicialização é sempre de 1024 bytes 
(dois setores do disco), mesmo que o MINIX 3 possa usar (e, por padrão, use) um tamanho 
de bloco maior em outros lugares. Quando o computador é ligado, o hardware lê o bloco de 
inicialização a partir do dispositivo de inicialização na memória, desvia para ele e começa a 
executar seu código. O código do bloco de inicialização inicia o processo de caraga do siste- 
ma operacional em si. Uma vez que o sistema tenha sido inicializado, o bloco de inicialização 
não será mais usado. Nem toda unidade de disco pode ser usada como dispositivo de iniciali- 
zação, mas para manter a estrutura uniforme, todo dispositivo de bloco tem um bloco reserva- 
do para código do bloco de inicialização. Na pior das hipóteses, essa estratégia desperdiça um 
bloco. Para impedir que o hardware tente inicializar a partir de um dispositivo inválido, um 
número mágico é armazenado em uma determinada posição do bloco de inicialização, quan- 
do, e somente quando, o código executável é escrito nesse dispositivo. Ao inicializar a partir 
de um dispositivo, o hardware (na verdade, o código da BIOS) se recusará a tentar carregar a 
partir de um dispositivo que não possua o número mágico. Isso impede o uso acidental de lixo 
como programa de inicialização. 

O superbloco (superblock) contém informações descrevendo o layout do sistema de 
arquivos. Assim como o bloco de inicialização, o superbloco tem sempre 1024 bytes, inde- 
pendentemente do tamanho de bloco usado para o restante do sistema de arquivos. Ele está 
ilustrado na Figura 5-35. 
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Número de i-nodes 


e na 
memória Tamanho máximo de arquivo 
Número de zonas 


Número mágico 


Ponteiro para o i-node da raiz do 
sistema de arquivos montado 
Ponteiro para o i-node 

montado 


i-nodes/bloco 
Presente na Número do dispositivo 
memória, 
mas não Flag somente para leitura 
no disco Flag nativo ou de byte trocado 
Versão do sistema de arquivos 
Zonas diretas/i-node 
Zonas indiretas/bloco de indireção simples 
Primeiro bit livre no mapa de bits de i-node 
Primeiro bit livre no mapa de bits de zona 


Figura 5-35 O superbloco do MINIX 3. 


) 
Tamanho do bloco (bytes) 


Versão de revisão do sistema de arquivos NY 


A principal função do superbloco é informar ao sistema de arquivos qual é o tamanho 
das suas várias partes. Dados o tamanho do bloco e o número de i-nodes, é fácil calcular o 
tamanho do mapa de bits de i-nodes e o número de blocos de i-nodes. Por exemplo, para um 
bloco de 1 KB, cada bloco do mapa de bits tem 1024 bytes (8192 bits) e, assim, pode moni- 
torar o status de até 8192 i-nodes. (Na verdade, o primeiro bloco pode manipular apenas até 
8191 i-nodes, pois não há nenhum i-node O, mas mesmo assim ele recebe um bit no mapa de 
bits). Para 10.000 i-nodes, são necessários dois blocos de mapa de bits. Como cada i-node 
ocupa 64 bytes, um bloco de 1 KB contém até 16 i-nodes. Com 64 i-nodes, quatro blocos de 
disco são necessários para conter todos eles. 

Explicaremos a diferença entre zonas e blocos em detalhes, posteriormente, mas por 
enquanto é suficiente dizer que o armazenamento em disco pode ser alocado em unidades 
(zonas) de 1, 2, 4, 8 ou, genericamente, 2” blocos. O mapa de bits de zona monitora o espaço 
de armazenamento livre em zonas, não em blocos. Para todos os discos padrão usados pelo 
MINIX 3, os tamanhos de zona e bloco são os mesmos (4 KB, por padrão): portanto, para 
uma primeira aproximação, zona é o mesmo que bloco nesses dispositivos. Até entrarmos nos 
detalhes da alocação de espaço de armazenamento, posteriormente neste capítulo, é adequado 
pensar em “bloco”, quando você ler “zona”. 
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Note que o número de blocos por zona não é armazenado no superbloco, pois ele nunca 
é necessário. Basta o logaritmo de base 2 da zona para se obter a relação com o número de 
blocos, o que é usado como contagem de deslocamento para converter zonas em blocos e 
vice-versa. Por exemplo, com 8 blocos por zona, log,8 = 3; portanto, para encontrar a zona que 
contém o bloco 128, deslocamos o número 128 3 bits para a direita, obtendo assim a zona 16. 

O mapa de bits de zona inclui apenas as zonas de dados (isto é, os blocos usados para os 
mapas de bits e para os i-nodes não estão no mapa), com a primeira zona de dados designada 
como zona 1 no mapa de bits. Assim como no mapa de bits de i-nodes, o bit O no mapa de 
zonas não é usado; portanto, o primeiro bloco no mapa de bits de zona pode fazer o mapea- 
mento de 8191 zonas e os blocos subsegiientes podem fazer o mapeamento de 8192 zonas 
cada um. Se você examinar os mapas de bits em um disco recém formatado, verá que os ma- 
pas de bits de i-node e de zona têm ambos 2 bits configurados como 1. Um deles serve para o 
i-node ou zona O inexistente e o outro serve para o i-node e zona usados pelo diretório-raiz no 
dispositivo, que é colocado lá quando o sistema de arquivos é criado. 

As informações presentes no superbloco são redundantes porque, às vezes são neces- 
sárias em uma forma e, às vezes, em outra. Com 1 KB dedicados ao superbloco, faz sentido 
calcular essas informações de todas as formas necessárias, em vez de ter de recalculá-las 
frequentemente, durante a execução. O número de zona da primeira zona de dados no disco, 
por exemplo, pode ser calculado a partir do tamanho do bloco, do tamanho da zona, do nú- 
mero de i-nodes e do número de zonas, mas é mais rápido apenas mantê-lo no superbloco. 
De qualquer forma, o restante do superbloco é desperdiçado; portanto, usar outra palavra dele 
não custa nada. 

Quando o MINIX 3 é inicializado, o superbloco do dispositivo-raiz é lido em uma ta- 
bela na memória. Analogamente, assim como acontece quando outros sistemas de arquivos 
são montados, seus superblocos também são levados para a memória. A tabela de superblocos 
contém vários campos que não estão presentes no disco. Isso inclui flags que permitem a um 
dispositivo ser especificado como somente para leitura ou como seguindo uma convenção 
de ordem de byte oposta ao padrão, e campos para acelerar o acesso, indicando pontos nos 
mapas de bits abaixo dos quais todos os bits estão marcados como usados. Além disso, existe 
um campo descrevendo o dispositivo de onde veio o superbloco. 

Antes que um disco possa ser usado como sistema de arquivos do MINIX 3, ele precisa 
receber a estrutura da Figura 5-34. O programa utilitário mkfs foi fornecido para construir 
sistemas de arquivos. Esse programa pode ser chamado por um comando como 


mkfs /dev/fd1 1440 


para construir um sistema de arquivos vazio de 1440 blocos no disquete, na unidade de disco 1, 
ou pode receber um arquivo listando os diretórios e arquivos a serem incluídos no novo sistema 
de arquivos. Esse comando também coloca um número mágico no superbloco para identificar o 
sistema de arquivos como válido no MINIX. O sistema de arquivos do MINIX evoluiu e alguns 
aspectos dele (por exemplo, o tamanho dos i-nodes) eram diferentes nas versões anteriores. O 
número mágico identifica a versão de mkfs que criou o sistema de arquivos, para que as dife- 
renças possam ser acomodadas. Tentativas de montar um sistema de arquivos que não esteja no 
formato do MINIX 3, como um disquete MS-DOS, serão rejeitadas pela chamada de sistema 
mount, que verifica o superbloco para encontrar um número mágico válido entre outras coisas. 


Mapas de bits 


O MINIX 3 monitora os i-nodes e as zonas livres usando dois mapas de bits. Quando um 
arquivo é removido, basta calcular qual bloco do mapa de bits contém o bit correspondente ao 
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i-node que está sendo liberado e encontrá-lo usando o mecanismo de cache normal. Uma vez 
encontrado o bloco, o bit correspondente ao i-node liberado é configurado como 0. As zonas 
são liberadas no mapa de bits de zona da mesma maneira. 

Logicamente, quando um arquivo precisa ser criado, o sistema de arquivos deve per- 
correr os blocos do mapa de bits, um por vez, para encontrar o primeiro i-node livre. Então, 
esse i-node é alocado para o novo arquivo. Na verdade, a cópia do superbloco que está na 
memória tem um campo que aponta para o primeiro i-node livre; portanto, nenhuma pesquisa 
é necessária até o i-node ser usado. Após o ponteiro deve ser atualizado para apontar para o 
próximo novo i-node livre, o qual, frequentemente, será o seguinte ou um que esteja próximo. 
Analogamente, quando um i-node é liberado, é feita uma verificação para ver se o i-node livre 
vem antes do que está sendo correntemente apontado e, se necessário, o ponteiro é atualiza- 
do. Se cada entrada de i-node no disco estiver cheia, a função de pesquisa retornará 0. Esse 
é o motivo pelo qual o i-node O não é usado (isto é, para que ele possa ser usado para indicar 
que a pesquisa falhou). Quando o programa mkfs cria um novo sistema de arquivos, ele zera 
o i-node O e configura o bit mais baixo no mapa de bits como 1, para que o sistema de arqui- 
vos nunca tente alocá-lo. Tudo que foi dito aqui sobre os mapas de bits de i-node também se 
aplica ao mapa de bits de zona; logicamente, sempre que for necessário espaço em disco, ele 
é pesquisado para se buscar a primeira zona livre. Novamente, para eliminar a maior parte das 
pesquisas sequenciais necessárias pelo mapa de bits, também é mantido um ponteiro para a 
primeira zona livre. 

Com esse conhecimento, podemos agora explicar a diferença entre zonas e blocos. A 
idéia por trás das zonas é ajudar a garantir que os blocos do disco pertencentes ao mesmo ar- 
quivo estejam localizados no mesmo cilindro, para melhorar o desempenho quando o arquivo 
for lido segiiencialmente. A estratégia escolhida é tornar possível alocar vários blocos por 
vez. Se, por exemplo, o tamanho do bloco for de 1 KB e o tamanho da zona for de 4 KB, o 
mapa de bits de zona monitorará as zonas e não os blocos. Um disco de 20 MB tem 5K zonas 
de 4 KB; portanto, 5K bits em seu mapa de zona. 

A maior parte do sistema de arquivos trabalha com blocos. As transferências de disco 
são feitas sempre um bloco por vez e a cache de buffer também trabalha com blocos indi- 
viduais. Apenas algumas partes do sistema que monitoram endereços de disco físicos (por 
exemplo, o mapa de bits de zona e os i-nodes) sabem a respeito das zonas. 

Algumas decisões de projeto tiveram de ser tomadas no desenvolvimento do sistema de 
arquivos do MINIX 3. Em 1985, quando o MINIX foi concebido, a capacidade dos discos era 
pequena e esperava-se que muitos usuários tivessem apenas disquetes. Foi tomada a decisão 
de restringir os endereços de disco a 16 bits no sistema de arquivos V1, principalmente para 
poder armazenar muitos deles em blocos de indireção. Com um número de zona de 16 bits 
e uma zona de 1 KB, apenas 64 KB zonas podem ser endereçadas, limitando os discos a 64 
MB. Essa era uma quantidade de armazenamento enorme naquela época e pensou-se que, à 
medida que os discos ficassem maiores, seria fácil trocar para zonas de 2 KB ou 4 KB, sem 
alterar o tamanho do bloco. Os números de zona de 16 bits também tornaram fácil manter o 
tamanho do i-node em 32 bytes. 

À medida que o MINIX se desenvolveu e discos maiores tornaram-se muito mais co- 
muns, ficou evidente que alterações eram desejáveis. Muitos arquivos são menores do que 
1 KB; portanto, aumentar o tamanho do bloco significaria desperdiçar largura de banda do 
disco, lendo e escrevendo blocos vazios e desperdiçando memória principal preciosa com seu 
armazenamento na cache de buffer. O tamanho da zona poderia ter sido aumentado, mas um 
tamanho de zona maior significaria mais espaço em disco desperdiçado e ainda era desejável 
manter a operação eficiente em discos pequenos. Uma alternativa razoável teria sido ter dife- 
rentes tamanhos de zona para se adaptar a dispositivos pequenos e grandes. 
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No final foi decidido aumentar o tamanho dos ponteiros de disco para 32 bits. Isso 
tornou possível para o sistema de arquivos da versão 2 do MINIX tratar com tamanhos de 
dispositivo de até 4 TB com blocos e zonas de 1 KB e 16 TB com blocos e zonas de 4 KB (o 
valor padrão, agora). Entretanto, outros fatores restringem esse tamanho (por exemplo, com 
ponteiros de 32 bits, o endereçamento “bruto” dentro de dispositivos está limitado a 4 GB). 
Aumentar o tamanho dos ponteiros de disco exigiu um aumento no tamanho dos i-nodes. Isso 
não é necessariamente ruim — significa que o i-node versão 2 (e, agora, o da versão 3) do MI- 
NIX é compatível com os i-nodes padrão do UNIX, com espaço para três valores de tempo, 
mais zonas indiretas e de dupla indireção, e espaço para expansão posterior com zonas com 
tripla indireção. 

As zonas também introduzem um problema inesperado, melhor ilustrado com um exem- 
plo simples, novamente com zonas de 4 KB e blocos de 1 KB. Suponha que um arquivo tenha 
comprimento de 1 KB, significando que uma zona foi alocada para ele. Os três blocos entre 
os deslocamentos 1024 e 4095 contêm lixo (resíduo do proprietário anterior), mas nenhum 
dano estrutural é causado no sistema de arquivos porque o tamanho do arquivo é claramente 
marcado no i-node como 1 KB. Na verdade, os blocos contendo lixo não serão lidos na cache 
de blocos, pois as leituras são feitas por blocos e não por zonas. As leituras além do fim de um 
arquivo sempre retornam uma contagem igual a 0 e nenhum dado. 

Agora, alguém busca 32.768 bytes e escreve 1 byte. Então, o tamanho do arquivo é 
configurado como 32.769. As buscas subsegiientes ao byte 1024 (imediatamente superior ao 
tamanho do bloco), seguidas de tentativas de leitura de dados, permitiria a leitura do conteúdo 
anterior do bloco, uma brecha séria na segurança. 

A solução é verificar essa situação quando é feita uma escrita que aumente o tamanho 
original do arquivo e zerar explicitamente todos os blocos ainda não alocados na zona. Em- 
bora essa situação raramente ocorra, o código tem de tratar dela, tornando o sistema ligeira- 
mente mais complexo. 


I-nodes 


O layout do i-node do MINIX 3 aparece na Figura 5-36. Ele é quase igual a um i-node padrão 
do UNIX. Os ponteiros de zona do disco têm 32 bits e existem apenas 9 deles, 7 diretos e 2 de 
indireção simples. Os i-nodes do MINIX 3 ocupam 64 bytes, o mesmo que os i-nodes padrão 
do UNIX, e há espaço disponível para um 10º ponteiro (indireção tripla), embora seu uso não 
seja suportado pela versão padrão do sistema de arquivos. Os tempos de acesso, modificação 
e alteração do i-node do MINIX 3 são padrão, como no UNIX. O último deles é atualizado 
para quase todas as operações de arquivo, exceto por uma leitura do arquivo. 

Quando um arquivo é aberto, seu i-node é localizado e trazido para a tabela inode na 
memória, onde permanece até que o arquivo seja fechado. A tabela inode tem alguns campos 
adicionais não presentes no disco, como o dispositivo e número do i-node, para que o sistema 
de arquivos saiba onde reescrever o i-node, caso ele seja modificado enquanto estiver na me- 
mória. Ela também tem um contador por i-node. Se o mesmo arquivo for aberto mais de uma 
vez, apenas uma cópia do i-node será mantida na memória, mas o contador será incrementado 
sempre que o arquivo for aberto e decrementado sempre que o arquivo for fechado. Somente 
quando o contador finalmente chegar a zero é que o i-node é removido da tabela. Se ele tiver 
sido modificado desde que foi carregado na memória, também será reescrito no disco. 

A principal função do i-node de um arquivo é informar onde estão os blocos de dados. 
Os sete primeiros números de zona são dados diretamente no próprio i-node. Para a distri- 
buição padrão, com zonas e blocos de 1 KB, arquivos de até 7 KB não precisam de blocos 
de indireção Além de 7 KB, zonas de indireção são necessárias, usando o esquema da Figura 
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16 bits 


| Modo | Tipo de arquivo e bits rwx 
Número de vínculos —— Entradas de diretório para esse arquivo 


—— Identifica o usuário que possui o arquivo 


| Ga | Grupo do proprietário 


Tamanho do arquivo —— Número de bytes no arquivo 


Raso Os tempos são todos em segundos, 
Hora da modificação desde 1º de Janeiro de 1970 
Hora da mudança de status 
64 bytes 
primeiras sete zonas 
Zona de indireção simples 
Usado para arquivos 
maiores do que 7 zonas 
Zona de indireção dupla 
É Nioutizado fo (Poderia ser usado para zona de indireção tripla) 


Figura 5-36 O i-node do MINIX. 


5-10, exceto que apenas os blocos de indireção simples e dupla são utilizados. Com blocos 
e zonas de 1 KB e números de zona de 32 bits, um único bloco de indireção simples contém 
256 entradas, representando um quarto de megabyte de armazenamento. O bloco de indireção 
dupla aponta para 256 blocos de indireção simples, fornecendo acesso a até 64 megabytes. 
Com blocos de 4 KB, o bloco de indireção dupla leva a 1024 x 1024 blocos, o que dá mais 
de um milhão de blocos de 4 KB, tornando o tamanho de arquivo máximo de mais de 4 GB. 
Na prática, o uso de números de 32 bits como deslocamentos de arquivo limita o tamanho 
de arquivo máximo a al bytes. Como consegiiência desses números, quando são usados 
blocos de disco de 4 KB, o MINIX 3 não tem necessidade de blocos de indireção tripla; o 
tamanho de arquivo máximo é limitado pelo tamanho do ponteiro e não pela capacidade de 
monitorar blocos suficientes. 

O i-node também contém a informação de modo, que indica qual é o tipo de um arquivo 
(normal, diretório, bloco especial, caractere especial ou pipe), e fornece a proteção e os bits 
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SETUID e SETGID. O campo número de vínculos no i-node registra quantas entradas de 
diretório apontam para esse i-node, para que o sistema de arquivos saiba quando deve liberar 
o espaço de armazenamento do arquivo. Esse campo não deve ser confundido com o contador 
(presente apenas na tabela inode na memória e não no disco), que informa quantas vezes o 
arquivo está correntemente aberto, normalmente por processos diferentes. 

Como uma observação final sobre os i-nodes, mencionamos que a estrutura da Figura 
5-36 pode ser modificada para propósitos especiais. Um exemplo usado no MINIX 3 são os 
i-nodes para arquivos especiais de dispositivo de bloco e caractere. Eles não precisam de pon- 
teiros de zona, pois não precisam referenciar áreas de dados no disco. Os números de disposi- 
tivo principal e secundário são armazenados no espaço Zona O na Figura 5-36. Outra maneira 
pela qual um i-node poderia ser usado, embora não implementada no MINIX 3, é como um 
arquivo imediato com um pequeno volume de dados armazenados no próprio i-node. 


A cache de blocos 


O MINIX 3 usa uma cache de blocos para melhorar o desempenho do sistema de arquivos. A 
cache é implementada como um conjunto fixo de buffers, cada um consistindo em um cabe- 
çalho contendo ponteiros, contadores e flags, e um com espaço para um bloco de disco. Todos 
os buffers que não estão em uso são concatenados em uma lista duplamente encadeada, do 
mais recentemente utilizado (MRU — most recently used) para o menos recentemente utiliza- 
do (LRU — least recently used), como ilustrado na Figura 5-37. 

Tabela hash 


Início (LRU) Fim (MRU) 


Figura 5-37 As listas encadeadas usadas pela cache de blocos. 


Além disso, para poder determinar rapidamente se um bloco dado está na cache ou não, 
é usada uma tabela hash. Todos os buffers contendo um bloco que tenha um código de hash 
igual a k são concatenados em uma lista encadeada simples apontada pela k-ésima entrada na 
tabela hash. A função de hash apenas extrai os n bits de ordem inferior do número do bloco, 
para que blocos de diferentes dispositivos apareçam no mesmo encadeamento de hash. Cada 
buffer está em um desses encadeamentos. Quando o sistema de arquivos é inicializado, todos 
os buffers não estão em uso, é claro, e todos estão em um encadeamento simples apontado 
pela entrada O da tabela de hash. Nesse momento, todas as outras entradas da tabela hash con- 
têm um ponteiro nulo, mas quando o sistema for posto em funcionamento, os buffers serão 
removidos do encadeamento 0 e outros encadeamentos serão construídos. 

Quando o sistema de arquivos precisa de um bloco, ele chama uma função, get block, a 
qual calcula o código de hash desse bloco e pesquisa a lista apropriada. Get block é chamada 
com um número de dispositivo e com um número de bloco, e a pesquisa compara os dois 
números com os campos correspondentes no encadeamento de buffers. Se for encontrado um 
buffer contendo o bloco, um contador no cabeçalho do buffer é incrementado para mostrar 
que o bloco está em uso e é retornado um ponteiro para ele. Se não for encontrado um bloco 
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na lista de hash, o primeiro buffer na lista LRU poderá ser usado; a informação armazenada 
poderá ser descartada para liberar o buffer. 

Uma vez escolhido um bloco da cache de blocos para ser usado, outro flag em seu cabe- 
çalho é verificado para ver se o mesmo foi modificado desde que foi carregado na cache. Se 
foi, ele é reescrito no disco. Nesse ponto, o bloco necessário é lido mediante o envio de uma 
mensagem para o driver de disco. O sistema de arquivos é suspenso até que o bloco chegue, 
momento este em que ele continua e um ponteiro para o bloco é retornado para o processo 
que fez a chamada. 

Quando a função que solicitou o bloco tiver terminado sua tarefa, ela chama outra fun- 
ção, put block, para liberar esse bloco. Normalmente, um bloco é usado imediatamente e 
depois liberado, mas como é possível que pedidos adicionais para um bloco sejam feitos 
antes que ele tenha sido liberado, put block decrementa o contador de uso e coloca o buffer 
de volta na lista LRU somente quando o contador de uso atingir zero. Enquanto o contador é 
diferente de zero, o bloco permanece no limbo. 

Um dos parâmetros de put block indica qual classe de bloco (por exemplo, i-nodes, diretó- 
rio, dados) está sendo liberada. Dependendo da classe, duas decisões importantes são tomadas: 


1. Colocar o bloco no início ou no fim da lista LRU. 


2. Escrever o bloco (se tiver sido modificado) no disco imediatamente ou não. 


Quase todos os blocos entram no fim da lista, no verdadeiro padrão LRU. A exceção são 
os blocos do disco de RAM; como eles já estão na memória, há pouca vantagem em mantê- 
los na cache de blocos. 

Um bloco modificado não é reescrito até que um de dois eventos ocorra: 


1. Ele chega no início do encadeamento LRU e deve liberar o espaço. 


2. Uma chamada de sistema sync é executada. 


Sync não percorre o encadeamento LRU, mas, em vez disso, indexa o conjunto de 
buffers na cache. Mesmo que um buffer não tenha ainda sido liberado, se ele tiver sido modi- 
ficado, sync o encontrará e garantirá que a cópia no disco será atualizada. 

Políticas como essa provocam remendos. Em uma versão antiga do MINIX, um su- 
perbloco era modificado quando um sistema de arquivos era montado e era sempre reescrito 
imediatamente para reduzir a chance de corromper o sistema de arquivos no caso de uma 
falha. Os superblocos são modificados apenas se o tamanho de um disco de RAM precisa ser 
ajustado no momento da inicialização, porque o disco de RAM foi criado com um tamanho 
maior do que o dispositivo da imagem da RAM. Entretanto, o superbloco não é lido nem 
escrito como um bloco normal, pois tem sempre tamanho de 1024 bytes, como o bloco de 
inicialização, independentemente do tamanho de bloco usado para blocos manipulados pela 
cache. Outra experiência abandonada foi que, nas versões anteriores do MINIX havia uma 
macro ROBUST que podia ser definida no arquivo de configuração do sistema, include/minix/ 
config.h, a qual, se definida, fazia o sistema de arquivos marcar blocos de i-node, diretório, 
indireção simples e de mapa de bits para serem escritos imediatamente após a liberação. Isso 
se destinava a tornar o sistema de arquivos mais robusto; o preço pago era uma operação 
mais lenta. Verificou-se que isso não era eficiente. Se ocorresse falta de energia quando todos 
os blocos ainda não tivessem sido escritos, seria uma dor de cabeça, caso fosse perdido um 
bloco de i-node ou de dados. 

Note que o flag do cabeçalho indicando que um bloco foi modificado é ativado pela 
função dentro do sistema de arquivos que solicitou e usou o bloco. As funções get block e 
put. block se preocupam apenas com a manipulação das listas encadeadas. Elas não têm a 
mínima idéia sobre qual função do sistema de arquivos deseja qual bloco ou por que. 
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5.6.6 Diretórios e caminhos 


Outro subsistema importante dentro do sistema de arquivos gerencia diretórios e nomes de 
caminho. Muitas chamadas de sistema, como open, têm um nome de arquivo como parâ- 
metro. O que é realmente necessário é o i-node desse arquivo; portanto, cabe ao sistema de 
arquivos procurar o arquivo na árvore de diretórios e localizar seu i-node. 

Um diretório do MINIX é um arquivo que, nas versões anteriores, continha entradas de 
16 bytes, 2 bytes para um número do i-node e 14 bytes para o nome de arquivo. Esse projeto 
limitava as partições de disco a arquivos de 64 KB e os nomes de arquivo a 14 caracteres, o 
mesmo que o UNIX V7. Quando os discos ficaram maiores, os nomes de arquivo também 
ficaram. No MINIX 3, o sistema de arquivos V3 fornece entradas de diretório de 64 bytes, 
com 4 bytes para o número do i-node e 60 bytes para o nome de arquivo. Ter até 4 bilhões de 
arquivos por partição de disco é efetivamente infinito e qualquer programador que escolha 
um nome de arquivo maior do que 60 caracteres deve ser mandado de volta à escola de pro- 
gramação. 

Note que caminhos como 


/usr/ast/ material do curso para este ano/sistemas. operacionais/exame-1.ps 


não estão limitados a 60 caracteres — apenas os nomes dos componentes individuais estão. 
O uso de entradas de diretório de comprimento fixo, neste caso, 64 bytes, é um exemplo de 
compromisso envolvendo simplicidade, velocidade e espaço de armazenamento. Outros sis- 
temas operacionais normalmente organizam os diretórios como uma lista, com um cabeçalho 
fixo para cada arquivo apontando para o próximo arquivo, sucessivamente, até atingir o final 
do diretório. O esquema do MINIX 3 é muito simples e praticamente não exigiu nenhuma 
alteração no código da versão 2. Ele também é muito rápido para pesquisa de nomes e para 
armazenar novos nomes, pois nenhum gerenciamento de listas é exigido. O preço pago é es- 
paço de armazenamento em disco desperdiçado, pois a maioria dos arquivos é muito menor 
do que 60 caracteres. 

Acreditamos piamente que otimizar para economizar espaço de armazenamento em 
disco (e algum espaço de armazenamento na RAM, pois ocasionalmente os diretórios estão 
na memória) é a escolha errada. A simplicidade e a correção do código devem vir primeiro e 
a velocidade deve vir logo depois. Com os discos modernos normalmente ultrapassando os 
100 GB, economizar uma pequena quantidade de espaço em disco ao preço de um código 
mais complicado e mais lento geralmente não é uma boa idéia. Infelizmente, muitos progra- 
madores cresceram em uma época de discos pequenos e memórias RAM menores ainda, e 
foram treinados desde o primeiro dia a resolver todos os compromissos entre complexidade 
e velocidade do código e espaço, favorecendo a minimização dos requisitos de espaço. Essa 
suposição implícita precisa ser revista à luz da realidade atual. 

Agora, vamos ver como o caminho /usr/ast/mbox/ é pesquisado. O sistema pesquisa 
primeiro usr no diretório-raiz, em seguida, pesquisa ast em /usr/e, finalmente, pesquisa mbox 
em /usr/ast/. A pesquisa real passa por um componente do caminho por vez, como ilustrado 
na Figura 5-16. 

A única complicação é o que acontece quando é encontrado um sistema de arquivos 
montado. A configuração normal do MINIX 3, e de muitos outros sistemas do tipo UNIX, é ter 
um sistema de arquivos raiz pequeno, contendo os arquivos necessários para iniciar o sistema 
e realizar sua manutenção básica, e ter a maioria dos arquivos, incluindo os diretórios dos 
usuários, em um dispositivo separado, montado em /usr. Este é um bom momento para vermos 
como é feita uma montagem de sistema de arquivos. Quando o usuário digita o comando 


mount /dev/cOd1 p2 /usr 
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no terminal, o sistema de arquivos contido no disco rígido 1, partição 2 é montado em /usr/ 
no sistema de arquivos raiz. Os sistemas de arquivos, antes e depois da montagem, aparecem 
na Figura 5-38. 

O segredo de toda a montagem é um flag ativado na cópia da memória do i-node de /usr 
após uma montagem bem-sucedida. Esse flag indica que o i-node está montado. A chamada 
mount também carrega na tabela super block o superbloco do sistema de arquivos recente- 
mente montado e configura dois ponteiros nela. Além disso, ela coloca o i-node raiz do siste- 
ma de arquivos montado na tabela inode. 

Na Figura 5-35, vemos que os superblocos na memória contêm dois campos relacio- 
nados aos sistemas de arquivos montados. O primeiro deles, i-node-raiz-do-sistema-de-ar- 
quivo-montado, é configurado de forma a apontar para o i-node raiz do sistema de arquivos 
recentemente montado. O segundo, i-node-montado, é configurado de forma a apontar para 
o i-node onde ocorreu a montagem, neste caso, o i-node de /usr. Esses dois ponteiros servem 
para conectar o sistema de arquivos montado à raiz e representam a “cola” que mantém o 
sistema de arquivos montado na raiz (mostrado como pontos na Figura 5-38(c)). Essa cola é 
o que faz os sistemas de arquivos montados funcionarem. 


Sistema de Sistema de arquivos 
arquivos raiz desmontado Após a montagem 


/ / / 


Nib /binNV/usr /bal Nib /binNV/usr 


/ast/f1 /last/f2 


/usr/bal lusr/ast 


lusr/ast/f2 


(a) (b) (c) 


Figura 5-38 (a) Sistema de arquivos raiz. (b) Um sistema de arquivos desmontado. (c) O 
resultado da montagem do sistema de arquivos de (b) em /usr/. 


Quando um caminho como /usr/ast/f2 estiver sendo pesquisado, o sistema de arquivos 
verá um flag no i-node de /usr/ e perceberá que deve continuar pesquisando o i-node raiz do 
sistema de arquivos montado em /usr/. A questão é: “como ele encontra esse i-node raiz?” 

A resposta é simples. O sistema pesquisa todos os superblocos na memória, até en- 
contrar aquele cujo campo i-node-montado aponte para /usr/. Esse deve ser o superbloco 
do sistema de arquivos montado em /usr/. Uma vez que tenha o superbloco, é fácil seguir o 
outro ponteiro para encontrar o i-node raiz do sistema de arquivos montado. Agora, o sistema 
de arquivos pode continuar a pesquisa. Neste exemplo, ele procura ast no diretório-raiz da 


partição 2 do disco rígido. 
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5.6.7 Descritores de arquivo 


Uma vez que um arquivo tenha sido aberto, um descritor de arquivo é retornado para o pro- 
cesso do usuário para uso nas chamadas de read e write subsequentes. Nesta seção, veremos 
como os descritores de arquivo são gerenciados dentro do sistema de arquivos. 

Assim como o núcleo e o gerenciador de processos, o sistema de arquivos mantém parte 
da tabela de processos dentro de seu espaço de endereçamento. Três de seus campos têm inte- 
resse especial. Os dois primeiros são ponteiros para os i-nodes do diretório-raiz e do diretório 
de trabalho. As pesquisas de caminho, como a da Figura 5-16, sempre começam em um ou no 
outro, dependendo de o caminho ser absoluto ou relativo. Esses ponteiros são alterados pelas 
chamadas de sistema chroot e chdir, para apontar para o novo diretório-raiz ou para o novo 
diretório de trabalho, respectivamente. 

O terceiro campo interessante na tabela de processos é um array indexado pelo número 
do descritor de arquivo. Ele é usado para localizar o arquivo correto quando um descritor de 
arquivo é apresentado. À primeira vista, poderia parecer suficiente fazer a k-ésima entrada 
desse array apenas apontar para o i-node do arquivo pertencente ao descritor de arquivo k. 
Afinal, o i-node é buscado na memória quando o arquivo é aberto e mantido lá até que ele seja 
fechado; portanto, seguramente ele está disponível. 

Infelizmente, esse plano simples tem uma falha, pois os arquivos podem ser compar- 
tilhados de maneiras sutis no MINIX 3 (assim como no UNIX). O problema surge porque, 
associado a cada arquivo existe um número de 32 bits que indica o próximo byte a ser lido 
ou escrito. É esse número, chamado de posição no arquivo, que é alterado pela chamada de 
sistema Iseek. O problema pode ser facilmente exposto: “onde o ponteiro de arquivo deve ser 
armazenado?” 

A primeira possibilidade é colocá-lo no i-node. Infelizmente, se dois ou mais processos 
tiverem o mesmo arquivo aberto ao mesmo tempo, todos deverão ter seus próprios ponteiros 
de arquivo, pois seria difícil fazer com que uma chamada Iseek realizada por um processo 
afetasse a próxima leitura de um processo diferente. Conclusão: a posição do arquivo não 
pode ser no i-node. 

Que tal colocá-la na tabela de processos? Por que não ter um segundo array, paralelo 
ao array de descritores de arquivo, fornecendo a posição corrente de cada arquivo? Essa idéia 
também não funciona, mas o raciocínio é mais sutil. Basicamente, o problema vem da se- 
mântica da chamada de sistema fork. Quando um processo executa um fork, o pai e o filho são 
obrigados a compartilhar um único ponteiro que fornece a posição corrente de cada arquivo 
aberto. 

Para entender melhor o problema, considere o caso de um script shell cuja saída foi 
redirecionada para um arquivo. Quando o shell cria o primeiro programa, sua posição de 
arquivo para a saída padrão é O. Então, essa posição é herdada pelo filho, o qual escreve, di- 
gamos, 1 KB nessa saída. Quando o filho termina, a posição do arquivo compartilhado deve 
ser agora 1024. 

Agora o shell Iê algo mais do script e cria outro filho. É fundamental que o segundo filho 
herde uma posição de arquivo igual a 1024 do shell; portanto, ele começará a escrever no lugar 
onde o primeiro programa parou. Se o shell não compartilhasse a posição do arquivo com seus 
filhos, o segundo programa sobrescreveria a saída do primeiro, em vez de anexar nela. 

Como resultado, não é possível colocar a posição do arquivo na tabela de processos. Ela 
realmente precisa ser compartilhada. A solução usada no UNIX e no MINIX 3 é introduzir 
uma nova tabela compartilhada, filp, contendo todas as posições de arquivo. Seu uso está ilus- 
trado na Figura 5-39. Tendo-se a posição do arquivo realmente compartilhada, a semântica 
do fork pode ser implementada corretamente e os scripts shell podem funcionar adequada- 
mente. 
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5.6.8 


5.6.9 


Tabela de 
Tabela filp i-nodes 


Tabela de 

processos 
Posição do arquivo 
Ponteiro do i-node 


e” Dm 


E= O © E, 


Figura 5-39 Como as posições de arquivo são compartilhadas entre um pai e um filho. 


Embora a única coisa que a tabela filp realmente precisa conter seja a posição do ar- 
quivo compartilhado, é conveniente também colocar lá o ponteiro do i-node. Desse modo, 
tudo que o array de descritores de arquivo na tabela de processos contém é um ponteiro para 
uma entrada de filp. A entrada de filp também contém o modo do arquivo (bits de permissão), 
alguns flags indicando se o arquivo foi aberto em um modo especial e uma contagem do 
número de processos que o estão utilizando, para que o sistema de arquivos possa identificar 
quando o último processo que está usando a entrada tiver terminado e reavê-la. 


Travamento de arquivos 


Um outro aspecto do gerenciamento do sistema de arquivos exige uma tabela especial. Tra- 
ta-se do travamento de arquivos. O MINIX 3 suporta o mecanismo de comunicação entre 
processos POSIX de travamento de arquivo consultivo (advisory file locking). Isso permite 
que qualquer parte ou que várias partes de um arquivo sejam marcadas como travadas. O sis- 
tema operacional não impõe o travamento, mas os processos devem ter bom comportamento 
e verificar se um arquivo possui travamentos antes de fazerem qualquer coisa que entre em 
conflito com outro processo. 

Os motivos para fornecer uma tabela separada para travas são semelhantes às justifica- 
tivas para a tabela filp discutida na seção anterior. Um único processo pode ter mais de um 
trava ativa e diferentes partes de um arquivo podem ser travadas por mais de um processo 
(embora, evidentemente, as travas não possam se sobrepor); portanto, nem a tabela de proces- 
sos nem a tabela filp é um bom lugar para registrar travas. Como um arquivo pode ter mais de 
uma trava em vigor, o i-node também não é um bom lugar. 

O MINIX 3 usa outra tabela, a tabela file lock, para registrar todas as travas. Cada en- 
trada nessa tabela tem espaço para o tipo de trava, indicando se o arquivo está travado (prote- 
gido) para leitura ou escrita, o ID do processo que mantém a trava, um ponteiro para o i-node 
do arquivo travado e os deslocamentos do primeiro e do último byte da região protegida por 
essa trava. 


Pipes e arquivos especiais 


Os pipes e arquivos especiais diferem dos arquivos normais de uma maneira importante. 
Quando um processo tenta ler ou escrever um bloco de dados de um arquivo do disco, é quase 
certo que a operação terminará, no máximo, dentro de poucas centenas de milissegundos. No 
pior caso, dois ou três acessos ao disco podem ser necessários, não mais do que isso. Ao ler 
um pipe, a situação é diferente: se o pipe estiver vazio, o leitor terá de esperar até que algum 
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outro processo coloque dados no pipe, o que poderia levar várias horas. Analogamente, ao ler 
de um terminal, um processo terá de esperar até que alguém digite alguma coisa. 

Como consegiiência, a regra normal do sistema de arquivos, de tratar de uma requisição 
até que ele tenha terminado, não funciona. É necessário suspender essas requisições e reini- 
ciá-las posteriormente. Quando um processo tenta ler ou escrever em um pipe, o sistema de 
arquivos pode verificar o estado do pipe imediatamente, para ver se a operação pode ser con- 
cluída. Se puder, ela será, mas se não puder, o sistema de arquivos registrará os parâmetros 
da chamada de sistema na tabela de processos, para que possa reiniciar o processo quando 
chegar a hora. 

Note que o sistema de arquivos não precisa executar nenhuma ação para suspender o 
processo que fez a chamada. Tudo que ele tem de fazer é abster-se de enviar uma resposta, 
deixando o processo que fez a chamada bloqueado, esperando pela resposta. Assim, após 
suspender um processo, o sistema de arquivos volta para seu laço principal para esperar pela 
próxima chamada de sistema. Assim que outro processo modifica o estado do pipe, para que 
o processo suspenso possa terminar, o sistema de arquivos ativa um flag para que, na próxima 
passagem pelo laço principal, ele extraia os parâmetros do processo suspenso da tabela de 
processos e execute a chamada. 

A situação no caso de terminais e outros arquivos especiais de caractere é ligeiramente 
diferente. O i-node de cada arquivo especial contém dois números: o de dispositivo princi- 
pal (major number) e o de dispositivo secundário (minor number). O número de dispositivo 
principal indica a classe do dispositivo (por exemplo, disco de RAM, disquete, disco rígido, 
terminal). Ele é usado como índice em uma tabela do sistema de arquivos que faz seu mapea- 
mento para o número do driver de dispositivo de E/S correspondente. Na verdade, o disposi- 
tivo principal determina o driver de E/S a ser chamado. O número de dispositivo secundário é 
passado para o driver como parâmetro. Ele especifica o dispositivo a ser usado, por exemplo, 
terminal 2 ou unidade de disco 1. 

Em alguns casos, principalmente nos dispositivos de terminal, o número de dispositivo 
secundário codifica algumas informações sobre uma categoria de dispositivos manipulada 
por um driver. Por exemplo, o console principal do MINIX 3, /dev/console, é o dispositivo 4, 
O (principal, secundário). Os consoles virtuais são manipulados pela mesma parte do software 
do driver. Esses são os dispositivos /dev/ttycl (4,1), /dev/ttyc2 (4,2) e assim por diante. Os 
terminais de linha serial precisam de um tratamento de software diferente e esses dispositi- 
vos, /dev/tty00 e /dev/tty01, recebem os números de dispositivo 4,16 e 4,17. Analogamente, 
os terminais de rede usam drivers de pseudoterminal e eles também precisam de tratamento 
específico. No MINIX 3, esses dispositivos, 1typ0, ttyp1 etc., recebem números de disposi- 
tivo como 4,128 e 4,129. Cada um desses pseudodispositivos tem um dispositivo associado, 
ptyp0, ptyp1 etc. Os pares número de dispositivo principal e secundário para eles são 4,192 
e 4,193 etc. Esses números foram escolhidos para tornar fácil para o driver de dispositivo 
chamar as funções de baixo nível exigidas para cada grupo de dispositivos. Não se espera que 
alguém equipe um sistema MINIX 3 com 192 terminais ou mais. 

Quando um processo lê um arquivo especial, o sistema de arquivos extrai os números de 
dispositivo principal e secundário do i-node do arquivo e usa o número de dispositivo princi- 
pal como índice em uma tabela do sistema de arquivos para mapear o número de processo do 
driver de dispositivo correspondente. Uma vez que tenha identificado o driver, o sistema de 
arquivos envia uma mensagem para ele, incluindo como parâmetros o dispositivo secundário, 
a operação a ser executada, o número de processo e o endereço do buffer do processo que fez 
a chamada, e a quantidade de bytes a serem transferidos. O formato é o mesmo da Figura 3- 
15, exceto que POSITION não é usado. 


CAPÍTULO 5 e SISTEMA DE ARQUIVOS 519 


5.6.10 


Se o driver for capaz de realizar o trabalho imediatamente (por exemplo, uma linha de 
entrada já foi digitada no terminal), ele copiará os dados de seus próprios buffers internos 
para o usuário e enviará para o sistema de arquivos uma mensagem de resposta dizendo que o 
trabalho está terminado. Então, o sistema de arquivos envia uma mensagem de resposta para 
o usuário e a chamada termina. Note que o driver não copia os dados no sistema de arquivos. 
Os dados de dispositivos de bloco passam pela cache de blocos, mas os dados de arquivos 
especiais de caractere, não. 

Por outro lado, se o driver não for capaz de realizar o trabalho, ele registrará os parâ- 
metros da mensagem em suas tabelas internas e enviará imediatamente uma resposta para o 
sistema de arquivos, dizendo que a chamada não pode ser concluída. Nesse ponto, o sistema 
de arquivos está na mesma situação de ter descoberto que alguém está tentando ler um pipe 
vazio. Ele registra o fato de que o processo está suspenso e espera pela próxima mensagem. 

Quando o driver tiver adquirido dados suficientes para completar a chamada, ele os 
transfere para o buffer do usuário que ainda está bloqueado e, então, enviará para o sistema 
de arquivos uma mensagem relatando o que fez. Tudo que o sistema de arquivos tem de fazer 
é enviar uma mensagem de resposta para o usuário, para desbloqueá-lo, e informar o número 
de bytes transferidos. 


Um exemplo: a chamada de sistema READ 


Conforme veremos em breve, a maior parte do código do sistema de arquivos é dedi- 
cada à execução de chamadas de sistema. Portanto, é adequado concluirmos esta visão geral 
com um breve esboço sobre o funcionamento da chamada mais importante, read. 

Quando um programa de usuário executa a instrução 


n = read(fd, buffer, nbytes); 


para ler um arquivo normal, a função de biblioteca read é chamada com três parâmetros. Ela 
constrói uma mensagem contendo esses parâmetros, junto com o código de read como o tipo 
da mensagem, e envia essa mensagem para o sistema de arquivos e bloqueia, esperando a 
resposta. Quando a mensagem chega, o sistema de arquivos usa o tipo da mensagem como 
índice em suas tabelas para chamar a função que trata da leitura. 

Essa função extrai o descritor de arquivo da mensagem e o utiliza para localizar a en- 
trada filp e, depois, o i-node do arquivo a ser lido (veja a Figura 5-39). Então, a requisição 
é dividida em partes, de modo que cada parte caiba dentro de um bloco. Por exemplo, se a 
posição do arquivo corrente é 600 e foram solicitados 1024 bytes, a requisição será dividida 
em duas partes, de 600 a 1023 e de 1024 a 1623 (supondo blocos de 1 KB). 

Para cada uma dessas partes, por sua vez, é feita uma verificação para ver se o bloco 
relevante está na cache. Se o bloco não estiver presente, o sistema de arquivos selecionará o 
buffer usado menos recentemente que não esteja em uso e o reivindicará, enviando uma men- 
sagem para o driver de dispositivo de disco para reescrevê-lo, caso esteja sujo. Então, o driver 
de disco é solicitado a buscar o bloco a ser lido. 

Quando o bloco estiver na cache, o sistema de arquivos enviará uma mensagem para 
a tarefa de sistema pedindo para que ela copie os dados no lugar apropriado no buffer do 
usuário (isto é, os bytes de 600 a 1023 no início do buffer e os bytes de 1024 a 1623 no 
deslocamento 424 dentro do buffer). Após a cópia ser feita, o sistema de arquivos envia uma 
mensagem de resposta para o usuário, especificando quantos bytes foram copiados. 

Quando a resposta volta para o usuário, a função de biblioteca read extrai o código da 
resposta e o retorna como o valor da função para o processo que fez a chamada. 
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Um passo extra não faz parte realmente da chamada de read em si. Depois que o sistema 
de arquivos conclui uma leitura e envia uma resposta, ele inicia a leitura de blocos adicionais, 
desde que a leitura seja a partir de um dispositivo de bloco e certas outras condições sejam 
satisfeitas. Como as leituras de arquivos sequenciais são comuns, é razoável esperar que os 
próximos blocos em um arquivo sejam solicitados na próxima requisição de leitura, e isso 
torna provável que o bloco desejado já esteja na cache quando for necessário. O número de 
blocos solicitados depende do tamanho da cache de blocos; até 32 blocos adicionais podem 
ser solicitados. O driver de dispositivo não retorna necessariamente essa quantidade de blo- 
cos e, se pelo menos um bloco for retornado, a requisição será considerada bem-sucedida. 


IMPLEMENTAÇÃO DO SISTEMA DE ARQUIVOS DO MINIX 3 


O sistema de arquivos do MINIX 3 é relativamente grande (mais de 100 páginas de código 
em C), mas muito simples. As requisições para executar chamadas de sistema chegam, são 
executadas e as respostas são enviadas. Nas seções a seguir, estudaremos um arquivo por vez, 
indicando os destaques. Existem muitos comentários no próprio código para ajudar o leitor. 

Ao examinarmos o código de outras partes do MINIX 3, geralmente olhamos primeiro 
o laço principal de um processo e depois as rotinas que manipulam os diferentes tipos de 
mensagem. Organizaremos nossa abordagem do sistema de arquivos de um modo diferente. 
Primeiro, estudaremos os subsistemas importantes (gerenciamento de cache, gerenciamento 
de i-nodes etc.). Depois, veremos o laço principal e as chamadas de sistema que operam sobre 
arquivos. Em seguida, veremos as chamadas de sistema que operam sobre diretórios e, então, 
discutiremos as chamadas de sistema restantes que não entram em nenhuma dessas catego- 
rias. Finalmente, veremos como os arquivos especiais de dispositivo são manipulados. 


Arquivos de cabeçalho e estruturas de dados globais 


Assim como no núcleo e no gerenciador de processos, várias estruturas de dados e tabelas 
usadas no sistema de arquivos são definidas em arquivos de cabeçalho. Algumas dessas es- 
truturas de dados são colocadas em arquivos de cabeçalho em nível de sistema, em include/ e 
seus subdiretórios. Por exemplo, include/sys/stat.h define o formato por meio do qual as cha- 
madas de sistema podem fornecer informações de i-node para outros programas e a estrutura 
de uma entrada de diretório é definida em include/sys/dir.h. Esses dois arquivos são exigidos 
pelo POSIX. O sistema de arquivos é afetado por várias definições contidas no arquivo de 
configuração global include/minix/config.h, como NR BUFSe NR BUF HASH, que contro- 
lam o tamanho da cache de blocos. 


Cabeçalhos do sistema de arquivos 


Os arquivos de cabeçalho do próprio sistema de arquivos estão no diretório de código-fonte 
do sistema de arquivos src/fs/. Muitos nomes de arquivo já são conhecidos do estudo de 
outras partes do sistema MINIX 3. O arquivo de cabeçalho mestre do sistema de arquivos 
(file system), fs.h (linha 20900), é muito parecido com src/kernel/kernel.h e src/pm/pm.h. Ele 
inclui outros arquivos de cabeçalho necessários para todos os arquivos-fonte em C no sistema 
de arquivos. Assim como acontece nas outras partes do MINIX 3, o cabeçalho-mestre do 
sistema de arquivos inclui os arquivos const.h, type.h, proto.h e glo.h do próprio sistema de 
arquivos. Veremos esses arquivos a seguir. 

Const.h (linha 21000) define algumas constantes, como os tamanhos de tabela e flags, 
que são usadas por todo o sistema de arquivos. O MINIX 3 já tem história. As versões ante- 
riores do MINIX tinham sistemas de arquivos diferentes. Embora o MINIX 3 não suporte os 
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antigos sistemas de arquivos das versões 1 e 2, algumas definições foram mantidas, tanto para 
referência como na expectativa de que alguém adicione suporte para eles posteriormente. 
O suporte para versões mais antigas é útil não apenas para acessar arquivos em sistemas de 
arquivos MINIX mais antigos, como também para a troca de arquivos. 

Outros sistemas operacionais podem usar sistemas de arquivos mais antigos do MINIX 
— por exemplo, originalmente, o Linux usava e ainda suporta sistemas de arquivos do MINIX. 
(Talvez seja um tanto irônico o fato de o Linux ainda suportar o sistema de arquivos original 
do MINIX, mas o MINIX 3 não suportar.) Estão disponíveis alguns utilitários do MS-DOS 
e do Windows para acessar diretórios e arquivos mais antigos do MINIX. O superbloco de 
um sistema de arquivos contém um número mágico para permitir que o sistema operacional 
identifique o tipo do sistema de arquivos; as constantes SUPER MAGIC, SUPER V2 e SU- 
PER V3 definem esses números para as três versões do sistema de arquivos do MINIX. Tam- 
bém existem versões deles, com sufixo REV, para o V1 e o V2, nas quais os bytes do número 
mágico são invertidos. Eles eram usados com portes das versões anteriores do MINIX para 
sistemas que usam uma ordem de byte diferente (little-endian, em vez de big-endian), para 
que um disco removível escrito em uma máquina com uma ordem de byte diferente pudesse 
ser identificado como tal. Na versão 3.1.0 do MINIX não foi necessário definir um número 
mágico SUPER V3 REV, mas é provável que essa definição seja adicionada no futuro. 

Type.h (linha 21100) define as estruturas de i-node V 1 antigas e V2 novas, conforme são 
dispostas no disco. O i-node é uma estrutura que não mudou no MINIX 3; portanto, o i-node 
V2 é usado com o sistema de arquivos V3. O i-node V2 é duas vezes maior do que o antigo, 
que foi projetado para ser compacto nos sistemas sem unidade de disco rígido e com disque- 
tes de 360 KB. A nova versão fornece espaço para os três campos de tempo que os sistemas 
UNIX fornecem. No i-node V1 havia apenas um campo de tempo, mas uma operação stat ou 
fstat “o falsificava” e retornava uma estrutura stat contendo todos os três campos. Há uma pe- 
quena dificuldade em oferecer suporte para as duas versões de sistema de arquivos. Isso está 
indicado pelo comentário na linha 21116. O software mais antigo do MINIX 3 esperava que o 
tipo gid t fosse um valor em 8 bits; portanto, d2_gid deve ser declarado como tipo ul6 1. 

Proto.h (linha 21200) fornece protótipos de função em formas aceitáveis para compila- 
dores K&R antigos ou ANSI C Standard, mais recentes. Trata-se de um arquivo longo, mas 
não tem grande interesse. Entretanto, há um ponto a destacar: como existem tantas chama- 
das de sistema diferentes manipuladas pelo sistema de arquivos e devido à maneira como o 
sistema de arquivos é organizado, as diversas funções do XXX estão espalhadas por vários 
arquivos. Proto.h é organizado por arquivo, e é uma maneira útil de encontrar o arquivo a 
ser consultado, quando você quiser ver o código que manipula uma chamada de sistema em 
particular. 

Finalmente, glo.h (linha 21400) define variáveis globais. Os buffers de mensagem para 
as mensagens recebidas e de resposta também estão aqui. O já conhecido truque com a macro 
EXTERN é usado, para que essas variáveis possam ser acessadas por todas as partes do siste- 
ma de arquivos. Assim como acontece nas outras partes do MINIX 3, o espaço de armazena- 
mento será reservado quando table.c for compilado. 

A parte do sistema de arquivos da tabela de processos está contida em fproc.h (linha 
21500). O array fproc é declarado com a macro EXTERN. Ele contém a máscara de modo, 
ponteiros para os i-nodes do diretório-raiz e do diretório de trabalho corrente, o array de des- 
critores de arquivo, uid, gid e o número de terminal para cada processo. O id de processo e o 
id de grupo do processo também são encontrados aqui. O id de processo é duplicado na parte 
da tabela de processos localizada no gerenciador de processos. 

Vários campos são usados para armazenar os parâmetros das chamadas de sistema que 
podem ser suspensas no meio do caminho, como as leituras de um pipe vazio. Os campos 
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fp suspended e fp revived exigem apenas bits simples, mas praticamente todos os compila- 
dores geram código melhor para caracteres do que para campos de bit. Também existe um 
campo para os bits FD CLOEXEC exigidos pelo padrão POSIX. Eles são usados para indicar 
se um arquivo deve ser fechado quando for feita uma chamada exec. 

Agora, chegamos aos arquivos que definem outras tabelas mantidas pelo sistema de ar- 
quivos. O primeiro, buf.h (linha 21600), define a cache de blocos. Todas as estruturas aqui são 
declaradas com EXTERN. O array buf contém todos os buffers, cada um dos quais contém 
uma parte de dados, b, e um cabeçalho repleto de ponteiros, flags e contadores. A parte dos 
dados é declarada como a união de cinco tipos (linhas 21618 a 21632), pois às vezes é conve- 
niente referir-se ao bloco como um array de caracteres, às vezes como um diretório etc. 

A maneira realmente correta de se referir à parte dos dados de buffer 3 como um ar- 
ray de caracteres é buf[3].b.b _data, pois bufl3].b se refere à união como um todo, a partir 
da qual o campo b _data é selecionado. Embora essa sintaxe esteja correta, ela é compli- 
cada; portanto, nas linha 21649, definimos uma macro b data, a qual nos permite escrever 
bufl3].b data em seu lugar. Note que b _data (o campo da união) contém dois sublinha- 
dos, enquanto b data (a macro) contém apenas um, para distingui-los. Macros para outras 
maneiras de acessar o bloco estão definidas nas linhas 21650 a 21655. 

A tabela hash para buffers, buf hash, é definida na linha 21657. Cada entrada aponta 
para uma lista de buffers. Originalmente, todas as listas estão vazias. As macros no final de 
buf.h definem diferentes tipos de bloco. O bit WRITE IMMED indica que um bloco deve 
ser reescrito imediatamente no disco, caso seja alterado, e o bit ONE SHOT é usado para 
indicar que um bloco provavelmente não será necessário em breve. Nenhum deles é usado 
atualmente, mas permanecem disponíveis para quem tiver uma idéia brilhante sobre como 
melhorar o desempenho, ou a confiabilidade, modificando a maneira como os blocos são 
enfileirados na cache. 

Finalmente, na última linha, HASH MASK é definida, baseada no valor de NR BUF HASH 
configurado em include/minix/config.h. HASH MASK é associada a um número de bloco por 
meio da operação lógica E, para determinar qual entrada em buf hash vai ser usada como ponto 
de partida em uma pesquisa de buffer de bloco. 

File.h (linha 21700) contém a tabela intermediária filp (declarada como EXTERN), usa- 
da para conter a posição do arquivo corrente e o ponteiro do i-node (veja a Figura 5-39). Ela 
também informa se o arquivo foi aberto para leitura, escrita ou ambos, e quantos descritores 
de arquivo estão correntemente apontando para a entrada. 

A tabela de travas de arquivo, file lock (declarada como EXTERN), está em lock.h (li- 
nha 21800). O tamanho do array é determinado por NR LOCKS, que é definida como 8 em 
const.h. Esse número deve ser aumentado, caso se queira implementar uma base de dados 
multiusuário em um sistema MINIX 3. 

Em inode.h (linha 21900), a tabela de i-nodes inode é declarada (usando EXTERN). 
Ela contém os i-nodes que estão correntemente em uso. Conforme dissemos anteriormente, 
quando um arquivo é aberto, seu i-node é lido na memória e mantido lá até que o arquivo seja 
fechado. A definição da estrutura inode fornece informações que são mantidas em memória, 
mas não são escritas no i-node do disco. Note que existe apenas uma versão e que, aqui, nada 
é específico da versão. Quando o i-node é lido do disco, são tratadas as diferenças entre os 
sistemas de arquivos V1 e V2/V3. O restante do sistema de arquivos não precisa saber sobre 
o formato do sistema de arquivos no disco, pelo menos até que chegue a hora de escrever 
informações modificadas. 

A maioria dos campos deve ser evidente neste ponto. Entretanto, i seek merece alguns 
comentários. Foi mencionado anteriormente que, como uma otimização, quando o sistema de 
arquivos nota que um arquivo está sendo lido sequencialmente, ele tenta ler blocos na cache, 
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mesmo antes de serem solicitados. Para arquivos acessados aleatoriamente não há nenhuma 
leitura antecipada. Quando é feita uma chamada Iseek, o campo i seek é configurado de for- 
ma a inibir a leitura antecipada (read ahead). 

O arquivo param.h (linha 22000) é análogo ao arquivo de mesmo nome no gerenciador 
de processos. Ele define nomes de campos de mensagem contendo parâmetros, para que o 
código possa se referir, por exemplo, a m_in. buffer, em vez dem in.ml pl, que seleciona um 
dos campos do buffer de mensagem m in. 

Em super.h (linha 22100), temos a declaração da tabela de superblocos. Quando o sis- 
tema é inicializado, o superbloco do dispositivo-raiz é carregado aqui. Quando os sistemas 
de arquivos são montados, seus superblocos ficam aqui também. Assim como acontece com 
outras tabelas, super block é declarada como EXTERN. 


Alocação de espaço de armazenamento no sistema de arquivos 


O último arquivo que discutiremos nesta seção não é um cabeçalho. Entretanto, exatamente 
como fizemos quando discutimos o gerenciador de processos, parece apropriado discutir- 
mos table.c imediatamente após examinarmos os arquivos de cabeçalho, pois todos eles são 
incluídos quando table.c (linha 22200) é compilado. A maioria das estruturas de dados que 
mencionamos — a cache de blocos, a tabela filp etc. — é definida com a macro EXTERN, 
como também as variáveis globais do sistema de arquivos e a parte da tabela de processos do 
sistema de arquivos. Da mesma maneira que vimos em outras partes do sistema MINIX 3, o 
espaço de armazenamento é reservado realmente quando table.c é compilado. Esse arquivo 
também contém um importante array inicializado. Call vector contém o array de ponteiros 
usado no laço principal para determinar qual função manipula qual número de chamada de 
sistema. Vimos uma tabela semelhante dentro do gerenciador de processos. 


Gerenciamento de tabelas 


Associado a cada uma das tabelas principais — blocos, i-nodes, superblocos etc. — está um 
arquivo que contém as funções que gerenciam a tabela. Essas funções são bastante utilizadas 
pelo restante do sistema de arquivos e formam a principal interface entre as tabelas e o siste- 
ma de arquivos. Por isso, é adequado iniciar com elas nosso estudo sobre o código do sistema 
de arquivos. 


Gerenciamento de blocos 


A cache de blocos é gerenciada pelas funções presentes no arquivo cache.c. Esse arquivo 
contém as nove funções listadas na Figura 5-40. A primeira delas, get block (linha 22426), é 
a maneira padrão pela qual o sistema de arquivos obtém blocos de dados. Quando uma função 
do sistema de arquivos precisa ler um bloco de dados do usuário, um bloco de diretório, um 
superbloco ou qualquer outro tipo de bloco, ela chama get block, especificando o dispositivo 
e o número do bloco. 

Quando get block é chamada, ela primeiro examina a cache de blocos para ver se o 
bloco solicitado está presente. Se estiver, é retornado um ponteiro para ele. Caso contrário, é 
preciso ler o bloco no disco. Os blocos na cache estão encadeados na lista NR BUF HASH. 
NR BUF HASH é um parâmetro que pode ser ajustado, junto com NR BUFS, o tamanho da 
cache de blocos. Ambos são configurados em include/minix/config.h. No final desta seção, 
falaremos um pouco sobre a otimização do tamanho da cache de blocos e da tabela hash. O 
valor de HASH MASK é NR BUF HASH- 1. Com 256 listas de hash, a máscara é 255; por- 
tanto, todos os blocos em cada lista têm números de bloco que terminam com a mesma string 
de 8 bits; isto é, 00000000, 00000001, ..., ou 11111111. 
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Função Descrição 
get block Buscar um bloco para leitura ou escrita 
put block Retornar um bloco solicitado anteriormente com get block 
alloc zone Alocar uma nova zona (para tornar um arquivo maior) 
free zone Liberar uma zona (quando um arquivo é removido) 
rw. block Transferir um bloco entre o disco e a cache 
invalidate Expurgar todos os blocos de cache de algum dispositivo 
flushall Descarregar todos os blocos modificados (sujos) de um dispositivo 
rw scattered | Ler ou escrever dados dispersos de (ou para) um dispositivo 
rm ru Remover um bloco de seu encadeamento LRU 


Figura 5-40 Funções usadas para gerenciamento de blocos. 


Normalmente, o primeiro passo é pesquisar um encadeamento hash em busca de um 
bloco, embora exista um caso especial, quando está sendo lida uma lacuna em um arquivo 
esparso, onde essa pesquisa é pulada. Esse é o motivo do teste na linha 22454. Caso contrário, 
as duas linhas seguintes põem bp de modo que aponte para o início da lista na qual o bloco 
solicitado estaria, caso estivesse na cache, aplicando HASH MASK no número do bloco. O 
laço na linha seguinte pesquisa essa lista para ver se o bloco pode ser encontrado. Se ele for 
encontrado e não estiver sendo usado, será removido da lista LRU. Se já estiver sendo usado, 
de qualquer forma não estará na lista LRU. O ponteiro para o bloco encontrado é retornado 
para o processo que fez a chamada, na linha 22463. 

Se o bloco não está na lista de hash, ele não está na cache; portanto, é tomado o bloco 
usado menos recentemente da lista LRU. O buffer escolhido é removido de seu encadeamento 
hash, pois está para receber um novo número de bloco e, assim, pertencerá a um encadeamen- 
to hash diferente. Se ele estiver sujo, será reescrito no disco, na linha 22495. Fazer isso com 
uma chamada para flushall implica em que sejam escritos todos os blocos sujos associados 
ao mesmo dispositivo. Essa chamada é a maneira pela qual a maioria dos blocos é escrita no 
disco. Os blocos que estão correntemente em uso nunca são escolhidos para descarregados, 
pois não estão no encadeamento LRU. Contudo, dificilmente os blocos serão encontrados em 
uso; normalmente, um bloco é liberado por put block imediatamente após se usado. 

Assim que o buffer estiver disponível, todos os campos, incluindo b dev, são atualiza- 
dos com os novos parâmetros (linhas 22499 a 22504) e o bloco pode ser lido do disco. Entre- 
tanto, existem duas ocasiões em que pode não ser necessário ler o bloco do disco. Get block é 
chamada com o parâmetro only search. Isso pode indicar que se trata de uma busca antecipa- 
da. Durante uma busca antecipada, um buffer disponível é encontrado, escrevendo o conteúdo 
antigo no disco, se necessário, e um novo número de bloco é atribuído ao buffer, mas o campo 
b dev é configurado como NO DEV para sinalizar que ainda não existem dados válidos nesse 
bloco. Veremos como isso é usado quando discutirmos a função rw scattered. Only search 
também pode ser usada para sinalizar que o sistema de arquivos precisa de um bloco apenas 
para reescrevê-lo inteiramente. Nesse caso, é desperdício ler primeiro a versão antiga. Em 
ambos os casos os parâmetros são atualizados, mas a leitura de disco real é omitida (linhas 
22507 a 22513). Quando o novo bloco for lido, get block retornará para o processo que fez 
sua chamada, com um ponteiro para o bloco. 

Suponha que o sistema de arquivos precise de um bloco de diretório temporariamente, 
para pesquisar um nome de arquivo. Ele chama get block para adquirir o bloco de diretório. 
Quando tiver pesquisado seu nome de arquivo, ele chamará put block (linha 22520) para re- 
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tornar o bloco para a cache, tornando assim o buffer disponível, para o caso de ser necessário 
posteriormente, para um bloco diferente. 

Put block coloca o bloco recentemente retornado na lista LRU e, em alguns casos, o 
reescreve no disco. Na linha 22544, é tomada a decisão de colocá-lo no início ou no fim da 
lista LRU. Os blocos em um disco de RAM são sempre colocados no início da fila. A cache 
de blocos não tem muita utilidade para um disco de RAM, pois seus dados já estão na me- 
mória e são acessíveis sem uma E/S real. O flag ONE SHOT é testado para ver se o bloco foi 
marcado como um que provavelmente não será necessário novamente em breve, e tais blocos 
são colocados no início, onde serão reutilizados rapidamente. Entretanto, isso raramente é 
usado, se é que será usado. Quase todos os blocos, exceto os do disco de RAM, são colocados 
no final, para o caso de serem necessários novamente em breve. 

Após o bloco ter sido reposicionado na lista LRU, é feita outra verificação para 
ver se ele deve ser escrito imediatamente no disco. Assim como o teste anterior, o teste 
de WRITE IMMED é um vestígio de uma experiência abandonada; atualmente, nenhum 
bloco é marcado para escrita imediata. 

À medida que um arquivo cresce, de tempos em tempos, uma nova zona precisa ser 
alocada para conter os novos dados. A função alloc zone (linha 22580) trata da alocação de 
novas zonas. Ela faz isso encontrando uma zona livre no mapa de bits de zona. Não haverá 
necessidade de pesquisar o mapa de bits se essa for a primeira zona em um arquivo; o campo 
s. zsearch no superbloco, que sempre aponta para a primeira zona disponível no dispositivo, 
é consultado. Caso contrário, é feita uma tentativa de encontrar uma zona próxima à última 
zona existente do arquivo corrente, para manter juntas as zonas de um arquivo. Isso é feito 
iniciando-se a pesquisa do mapa de bits nessa última zona (linha 22603). O mapeamento en- 
tre o número do bit no mapa de bits e o número da zona é realizado na linha 22615, com o bit 
1 correspondendo à primeira zona de dados. 

Quando um arquivo é removido, suas zonas devem ser retornadas para o mapa de bits. 
Free zone (linha 22621) é responsável por retornar essas zonas. Tudo que ela faz é chamar 
free. bit, passando o mapa de zonas e o número do bit como parâmetros. Free bit também é 
usada para retornar i-nodes livres, mas, então, com o mapa de i-nodes como primeiro parâ- 
metro, é claro. 

Gerenciar a cache exige ler e escrever blocos. Para fornecer uma interface de disco 
simples, foi fornecida a função rw block (linha 22641). Ela lê ou escreve um bloco. Analoga- 
memte, rw inode existe para ler e escrever i-nodes. 

A função seguinte no arquivo é invalidate (linha 22680). Ela é chamada quando um 
disco é desmontado, por exemplo, para remover da cache todos os blocos pertencentes ao 
sistema de arquivos que acabou de ser desmontado. Se isso não fosse feito, então, quando 
o dispositivo fosse reutilizado (com um disquete diferente), o sistema de arquivos poderia 
encontrar os blocos antigos, em vez dos novos. 

Mencionamos anteriormente que flushall (linha 22694), chamada a partir de get block 
quando um bloco sujo é removido da lista LRU, é a função responsável por escrever a maio- 
ria dos dados. Ela também é chamada pela chamada de sistema sync, para descarregar no 
disco todos os buffers sujos pertencentes a um dispositivo específico. Sync é ativada perio- 
dicamente pelo daemon de atualização e chama flushall uma vez para cada dispositivo mon- 
tado. Flushall trata a cache de buffer como um array linear, de modo que todos os buffers 
sujos são encontrados, mesmo aqueles que estão correntemente em uso e não estão na lista 
LRU. Todos os buffers na cache são percorridos e aqueles que pertencem ao dispositivo a 
ser descarregado, e que precisam ser escritos, são adicionados em um array de ponteiros, 
dirty. Esse array é declarado como static para mantê-lo fora da pilha. Então, ele é passado 
para rw scattered. 
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No MINIX 3, o escalonamento de escrita em disco foi removido dos drivers de dispo- 
sitivo de disco e tornou-se responsabilidade exclusiva de rw. scattered (linha 22711). Essa 
função recebe um identificador de dispositivo, um ponteiro para um array de ponteiros para 
buffers, o tamanho do array e um flag indicando se a operação é de leitura ou escrita. A 
primeira coisa que ela faz é ordenar o array que recebe pelos números de bloco, para que 
a operação de leitura ou escrita seja realizada em uma ordem eficiente. Então, ela constrói 
vetores de blocos adjacentes para enviar para o driver de dispositivo com uma chamada para 
dev io. O driver não precisa fazer nenhum escalonamento adicional. Com um disco moder- 
no, é provável que os circuitos eletrônicos da unidade de disco otimizem ainda mais a ordem 
das requisições, mas isso não é visível para o MINIX 3. Rw scattered é chamada com o flag 
WRITING apenas a partir da função flushall descrita anteriormente. Nesse caso, a origem 
desses números de bloco é fácil de entender. Eles são buffers que contêm dados de blocos 
lidos anteriormente, mas agora modificados. A única chamada para rw scattered para uma 
operação de leitura é a partir de rahead em read.c. Nesse ponto, precisamos saber apenas que, 
antes de chamar rw. scattered, get block foi chamada repetidamente no modo de busca ante- 
cipada, reservando assim um grupo de buffers. Esses buffers contêm números de bloco, mas 
nenhum parâmetro de dispositivo válido. Isso não é problema, pois rw scattered é chamada 
com um parâmetro de dispositivo como um de seus argumentos. 

Há uma diferença importante na maneira como um driver de dispositivo pode responder a 
uma requisição de leitura (em oposição a uma escrita) a partir de rw scattered. Uma requisição 
de escrita de vários blocos precisa ser atendida completamente, mas uma requisição de leitura 
de vários blocos pode ser tratada de forma diversa por diferentes drivers, dependendo do que 
for mais eficiente para o driver em particular. Rahead frequentemente chama rw scattered 
requisitando uma lista de blocos que podem não ser realmente necessários; portanto, a melhor 
resposta é fornecer o máximo de blocos que possam ser obtidos facilmente, mas não fazer 
buscas alucinadas por todo um dispositivo, o que pode levar a um tempo de busca substancial. 
Por exemplo, o driver de disquete pode parar em um limite de trilha e muitos outros drivers 
lerão apenas blocos consecutivos. Quando a leitura termina, rw scattered marca os blocos lidos 
preenchendo o campo de número de dispositivo em seus buffers de bloco. 

A última função na Figura 5-40 é rm Iru (linha 22809). Essa função é usada para remo- 
ver um bloco da lista LRU. Ela é usada apenas por get block nesse arquivo, de modo que é 
declarada como PRIVATE, em vez de PUBLIC, para ocultá-la de funções de fora do arquivo. 

Antes de concluirmos a cache de blocos, vamos dizer algumas coisas sobre sua oti- 
mização. NR BUF HASH deve ser uma potência de 2. Se for maior do que NR BUFS, o 
comprimento médio de um encadeamento hash será menor do que um. Se houver memória 
suficiente para um número grande de buffers, haverá espaço para um número grande de enca- 
deamentos hash; portanto, a escolha usual é tornar NR BUF HASH a próxima potência de 2 
maior do que NR BUFS. A listagem no texto mostra configurações de 128 blocos e 128 listas 
de hash. O tamanho ótimo depende de como o sistema é usado, pois isso determina o quanto 
deve ser colocado em buffer. O código-fonte completo usado para compilar os binários pa- 
drão do MINIX 3, que são instalados a partir do CD-ROM que acompanha este texto, tem 
configurações de 1280 buffers e 2048 encadeamentos hash. Empiricamente, foi determinado 
que aumentar o número de buffers além disso não melhorava o desempenho ao se recompilar 
o sistema MINIX 3; portanto, aparentemente isso é grande o suficiente para conter os binários 
de todas as passagens do compilador. Para algum outro tipo de trabalho, um tamanho menor 
poderia ser adequado ou um tamanho maior poderia melhorar o desempenho. 

Os buffers do sistema MINIX 3 padrão no CD-ROM ocupam mais de 5 MB de memó- 
ria RAM. É fornecido um binário adicional, designado como image small, que foi compilado 
com apenas 128 buffers na cache de blocos e os buffers para esse sistema só precisam de pou- 
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co mais do que 0,5 MB. Isso pode ser instalado em um sistema com apenas 8 MB de memória 
RAM. A versão padrão exige 16 MB de memória RAM. Com jeito, ele sem dúvida poderia 
caber em uma memória de 4 MB ou menos. 


Gerenciamento de i-nodes 


A cache de blocos não é a única tabela do sistema de arquivos que precisa de funções de 
suporte. A tabela de i-nodes também. Muitas funções têm função semelhante às funções de 
gerenciamento de bloco. Elas estão listadas na Figura 5-41. 


Função Descrição 
get inode Obter um i-node na memória 
put inode Devolver i-node que não é mais necessário 
alloc inode Alocar um novo i-node (para um novo arquivo) 
wipe inode Limpar alguns campos em um i-node 
free inode Liberar um i-node (quando um arquivo é removido) 


update times 


Atualizar campos de tempo em um i-node 


rw inode Transferir um i-node entre a memória e o disco 
old icopy Converter o conteúdo do i-node para escrever no i-node de disco 
(versão 1) 
new icopy Converter os dados lidos do i-node de disco do sistema de arquivos 
(versão 1) 
dup. inode Indicar que o i-node já está em uso 
Figura 5-41 Funções usadas para gerenciamento de i-node. 


A função get inode (linha 22933) é análoga a get block. Quando qualquer parte do sis- 
tema de arquivos precisa de um i-node, ela chama get inode para adquiri-lo. Get inode pri- 
meiro pesquisa a tabela inode para ver se o i-node está presente. Se estiver, ela incrementa o 
contador de utilização e retorna um ponteiro para o nó. Essa pesquisa está contida nas linhas 
22945 a 22955. Se o i-node não estiver presente na memória, ele será carregado chamando-se 
rw inode. 

Quando a função que precisou do i-node terminar de usá-lo, o i-node é devolvido pela 
chamada da função put inode (linha 22976), a qual decrementa o contador de utilização 
i count. Se, então, a contagem for zero, o arquivo não está mais sendo usado e o i-node pode 
ser removido da tabela. Se ele estiver sujo, será reescrito no disco. 

Se o campo i link é zero, nenhuma entrada de diretório está apontando para o arquivo; 
portanto, todas as suas zonas podem ser liberadas. Note que o contador de utilização se tornar 
zero e o número de vínculos se tornar zero são eventos diferentes, com diferentes causas e 
consegiiências. Se o i-node é para um pipe, todas as zonas devem ser liberadas, mesmo que o 
número de vínculos possa não ser zero. Isso acontece quando um processo que está lendo um 
pipe libera o pipe. Não tem sentido possuir um pipe para um único processo. 

Quando um novo arquivo é criado, um i-node deve ser alocado por alloc inode (linha 
23003). O MINIX 3 permite a montagem de dispositivos no modo somente para leitura; 
portanto, o superbloco é verificado para garantir que o dispositivo seja gravável. Ao contrário 
das zonas, onde é feita uma tentativa de manter as zonas de um arquivo próximas, qualquer 
i-node servirá. Para poupar o tempo de pesquisar o mapa de bits de i-nodes, tira-se proveito 
do campo no superbloco onde é registrado o primeiro i-node não utilizado. 
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Depois que o i-node for adquirido, get inode é chamada para buscar o i-node na tabela, 
na memória. Então, seus campos são inicializados, parcialmente, um a um (linhas 23038 a 
23044), e usando a função wipe inode (linha 23060). Essa divisão de trabalho em particular 
foi escolhida porque wipe inode também é necessária em outra parte do sistema de arquivos, 
para limpar certos campos de i-node (mas não todos eles). 

Quando um arquivo é removido, seu i-node é liberado pela chamada de free inode (linha 
23079). Tudo que acontece aqui é que o bit correspondente no mapa de bits de i-nodes é confi- 
gurado como 0 e o registro do superbloco do primeiro i-node não utilizado é atualizado. 

A próxima função, update times (linha 23099), é chamada para obter o tempo do reló- 
gio do sistema e alterar os campos de tempo que exigem atualização. Update times também é 
chamada pelas chamadas de sistema stat e fstat, de modo que é declarada como PUBLIC. 

A função rw inode (linha 23125) é análoga a rw block. Sua tarefa é buscar um i-node 
do disco. Ela realiza seu trabalho executando os seguintes passos: 


1. Calcular qual bloco contém o i-node exigido. 
2. Ler o bloco, chamando get block. 

3. Extrair o i-node e copiá-lo na tabela inode. 
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. Retornar o bloco, chamando put block. 


Rw inode é um pouco mais complexa do que o esboço básico dado acima, de modo que 
algumas funções adicionais são necessárias. Primeiro, como obter o tempo corrente exige 
uma chamada de núcleo, qualquer necessidade de alteração nos campos de tempo no i-node 
é apenas marcada, configurando-se bits no campo i update do i-node, enquanto o i-node 
está na memória. Se esse campo for diferente de zero quando um i-node precisar ser escrito, 
update times será chamada. 

Segundo, a história do MINIX acrescenta uma complicação: no sistema de arquivos 
antigo da versão 1 (V1), os i-nodes no disco têm uma estrutura diferente da versão 2 (V2). 
Duas funções, old icopy (linha 23168) e new icopy (linha 23214), são fornecidas para tratar 
das conversões. A primeira faz a conversão entre as informações de i-node na memória e o 
formato usado pelo sistema de arquivos V7. A segunda faz a mesma conversão para discos 
dos sistemas de arquivos V2 e V3. Essas duas funções são chamadas apenas dentro desse 
arquivo, de modo que são declaradas como PRIVATE. Cada função manipula conversões nas 
duas direções (do disco para a memória ou da memória para o disco). 

As versões antigas do MINIX foram portadas para sistemas que usavam uma ordem de 
byte diferente dos processadores Intel e o MINIX 3 provavelmente também será portado para 
essas arquiteturas no futuro. Toda implementação usa a ordem de byte nativa em seu disco; 
o campo sp->native no superbloco identifica qual ordem é usada. Tanto old icopy como 
new icopy chamam as funções conv2 e conv4 para trocar as ordens de byte, se necessário. 
É claro que grande parte do que acabamos de descrever não é usada pelo MINIX 3, pois ele 
não suporta o sistema de arquivos V1 a ponto de discos V1 poderem ser usados. E quando 
este livro estava sendo produzido, ninguém havia portado o MINIX 3 para uma plataforma 
que utilizasse uma ordem de byte diferente. Mas esses itens permanecem lá para o dia em que 
alguém decida tornar o MINIX 3 mais versátil. 

A função dup inode (linha 23257) apenas incrementa o contador de utilização do i- 
node. Ela é chamada quando um arquivo aberto é novamente aberto. Na segunda abertura, o 
i-node não precisa ser buscado do disco outra vez. 


Gerenciamento de superbloco 


O arquivo super.c contém funções que gerenciam o superbloco e os mapas de bits. Seis fun- 
ções são definidas nesse arquivo e estão listadas na Figura 5-42. 
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Função Descrição 

alloc bit Alocar um bit do mapa de zonas ou de i-nodes 

free bit Liberar um bit no mapa de zonas ou de i-nodes 

get super Procurar um dispositivo na tabela de tabela de superblocos 


get block size | Encontrar tamanho de bloco para usar 


mounted Informar se determinado i-node está em um sistema de arquivos 
montado (ou raiz) 


read super Ler um superbloco 


Figura 5-42 Funções usadas para gerenciar o superbloco e mapas de bits. 


Quando um i-node ou uma zona é necessária, alloc inode ou alloc zone é chamada, 
conforme vimos anteriormente. Ambas chamam alloc bit (linha 23324) para realmente pes- 
quisar o mapa de bits relevante. A pesquisa envolve três laços aninhados, como segue: 


1. O laço externo percorre todos os blocos de um mapa de bits. 
2. O laço do meio percorre todas as palavras de um bloco. 


3. O laço interno percorre todos os bits de uma palavra. 


O laço do meio funciona vendo se a palavra corrente é igual ao complemento de um de 
zero; isto é, uma palavra apenas com valores binários 1. Se for, ela não tem i-nodes ou zonas 
livres; portanto, a próxima palavra é tentada. Quando for encontrada uma palavra com um 
valor diferente, ela deverá conter pelo menos um bit 0; portanto, entra-se no laço interno para 
encontrar o bit livre (isto é, 0). Se todos os blocos foram testados sem sucesso, não existem 
i-nodes ou zonas livres; portanto, é retornado o código NO BIT (0). Pesquisas como essa po- 
dem consumir muito tempo do processador, mas o uso dos campos do superbloco que apon- 
tam para o primeiro i-node e zona não utilizados, passados para alloc bit em origin, ajuda a 
manter essas pesquisas curtas. 

Liberar um bit é mais simples do que alocar, pois nenhuma pesquisa é exigida. Free bit 
(linha 23400) calcula qual bloco do mapa de bits contém o bit a ser liberado e configura 
o bit correto como 0, chamando get block, zerando o bit na memória e, então, chamando 
put. block. 

A função seguinte, get super (linha 23445), é usada para pesquisar a tabela de super- 
blocos em busca de um dispositivo específico. Por exemplo, quando um sistema de arquivos 
precisa ser montado, é necessário verificar se ele já não está montado. Essa verificação pode 
ser realizada pedindo-se para que get super encontre o dispositivo do sistema de arquivos. Se 
ela não encontrar o dispositivo, então o sistema de arquivos não está montado. 

No MINIX 3, o servidor de sistema de arquivos é capaz de tratar de sistemas de arquivos 
com tamanhos de bloco diferentes, embora dentro de determinada partição de disco apenas 
um tamanho de bloco possa ser utilizado. A função get block size (linha 23467) destina-se a 
determinar o tamanho do bloco de um sistema de arquivos. Ela pesquisa a tabela de superblo- 
cos para encontrar o dispositivo dado e retorna o tamanho do bloco do dispositivo, se estiver 
montado. Caso contrário, é retornado o tamanho de bloco mínimo, MIN BLOCK SIZE. 

A próxima função, mounted (linha 23489), é chamada somente quando um dispositivo 
de bloco é fechado. Normalmente, todos os dados colocados na cache de um dispositivo são 
descartados quando ele é fechado. Mas se o dispositivo estiver montado, isso não é desejável. 
Mounted é chamada com um ponteiro para o i-node de um dispositivo. Ela apenas retorna 
TRUE se o dispositivo for o dispositivo-raiz ou se for um dispositivo montado. 


530 


SISTEMAS OPERACIONAIS 


Finalmente, temos read super (linha 23509). Ela é parcialmente semelhante a rw block 
erw inode, mas é chamada somente para leitura. O superbloco não é lido na cache de blocos; 
uma requisição é feita diretamente para o dispositivo, para 1024 bytes a partir de um deslo- 
camento da mesma quantidade, a partir do início do dispositivo. A escrita de um superbloco 
não é necessária na operação normal do sistema. Read super verifica a versão do sistema de 
arquivos do qual acabou de ler e realiza as conversões, se necessário, para que a cópia do su- 
perbloco na memória tenha a estrutura padrão, mesmo ao ler de um disco com uma estrutura 
de superbloco ou uma ordem de byte diferente. 

Mesmo não sendo atualmente usado no MINIX 3, o método de determinar se um disco 
foi escrito em um sistema com uma ordem de byte diferente é inteligente e vale a menção. O 
número mágico de um superbloco é escrito com a ordem de byte nativa do sistema no qual o 
sistema de arquivos foi criado e, quando um superbloco é lido, é feito um teste para superblo- 
cos com ordem de byte invertida. 


Gerenciamento de descritores de arquivo 


O MINIX 3 contém funções especiais para gerenciar descritores de arquivo e a tabela filp 
(veja a Figura 5-39). Elas estão contidas no arquivo filedes.c. Quando um arquivo é criado 
ou aberto, são necessários um descritor de arquivo livre e uma entrada livre de filp. A função 
get fd (linha 23716) é usada para encontrá-los. Entretanto, eles não são marcados como em 
uso, pois muitas verificações precisam ser feitas primeiro, antes que se saiba com certeza que 
a operação creat ou open será bem-sucedida. 

Get filp (linha 23761) é usada para ver se um descritor de arquivo está no intervalo e, 
se estiver, retorna seu ponteiro filp. 

A última função nesse arquivo é find filp (linha 23774). Ela é necessária para se desco- 
brir quando um processo está escrevendo em um pipe quebrado (isto é, um pipe que não foi 
aberto para leitura por nenhum outro processo). Ela localiza leitores em potencial por meio 
de uma pesquisa de força bruta da tabela filp. Se não puder encontrar um leitor, o pipe será 
quebrado e a escrita falhará. 


Travamento de arquivos 


As funções de travamento do POSIX aparecem na Figura 5-43. Uma parte de um arquivo 
pode ser protegida para leitura e escrita ou apenas para escrita, por uma chamada fentl espe- 
cificando uma requisição de F SETLK ou F SETLKW. O fato de existir uma trava em uma 
parte de um arquivo pode ser determinado usando-se a requisição F GETLK. 


Operação Descrição 


F SETLK Trava a região para leitura e para escrita 


F SETLKW | Trava a região para escrita 


F GETLK Informa se a região está travada 


Figura 5-43 As operações de travamentodo POSIX. Essas operações são solicitadas usan- 
do-se uma chamada de sistema FCNTL. 


O arquivo lock.c contém apenas duas funções. Lock op (linha 23820) é chamada pela 
chamada de sistema fcntl com o código de uma das operações mostradas na Figura 5-43. 
Ela faz algumas verificações de erro para certificar-se de que a região especificada é válida. 
Quando uma trava está sendo estabelecida, ela não deve entrar em conflito com outra já exis- 
tente, e quando uma trava está sendo liberada, uma trava já existente não deve ser dividida 
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em duas. Quando qualquer trava é retirada, a outra função nesse arquivo, lock revive (linha 
23964), é chamada. Ela desperta todos os processos que estão bloqueados esperando por 
liberação dos travamentos. 

Essa estratégia é um compromisso: ela deve usar código extra para descobrir exatamen- 
te quais processos estão esperando que uma trava em particular seja liberada. Os processos 
que ainda estão esperando por um arquivo com travamento serão bloqueados novamente, 
quando iniciarem. Essa estratégia é baseada na suposição de que travas raramente serão usa- 
das. Se uma base de dados multiusuário importante tivesse de ser construída em um sistema 
MINIX 3, poderia ser desejável reimplementar isso. 

Lock revive também é chamada quando um arquivo com travamento é fechado, como 
poderia acontecer, por exemplo, se um processo fosse eliminado antes de terminar de usar um 
arquivo com travamento. 


O programa principal 

O laço principal do sistema de arquivos está contido no arquivo main.c, (linha 24040). Após 
uma chamada para fs. init, para inicialização, entra-se no laço principal. Estruturalmente, ele 
é muito parecido com o laço principal do gerenciador de processos e dos drivers de disposi- 
tivo de E/S. A chamada de get work espera a chegada da próxima mensagem de requisição 
(a não ser que um processo anteriormente suspenso em um pipe ou terminal agora possa ser 
manipulado). Ela também configura uma variável global, who, com o número da entrada da 
tabela de processos do processo que fez a chamada, e outra variável global, call nr, com o 
número da chamada de sistema a ser executada. 

Uma vez de volta ao laço principal, a variável fp é apontada para a entrada da tabela 
de processos do processo que fez a chamada e o flag super user informa se esse processo 
é o superusuário ou não. As mensagens de notificação têm alta prioridade e a existência de 
uma mensagem SYS SIG é verificada primeiro, para ver se o sistema está sendo desligado. A 
segunda prioridade mais alta é uma mensagem SYN ALARM, que significa que um tempo- 
rizador configurado pelo sistema de arquivos expirou. Uma mensagem NOTIFY MESSAGE 
significa que um driver de dispositivo está pronto para receber atenção e é despachada para 
dev status. Então, vem a atração principal — a chamada para a função que executa a chama- 
da de sistema. A função a ser chamada é selecionada usando-se call nr como índice no array 
de ponteiros de função, call vecs. 

Quando o controle volta para o laço principal, se dont reply tiver sido configurada, a 
resposta será inibida (por exemplo, um processo foi bloqueado tentando ler um pipe vazio). 
Caso contrário, uma resposta será enviada pela chamada de reply (linha 24087). A última 
instrução no laço principal foi projetada para detectar se um arquivo está sendo lido segiien- 
cialmente e para carregar o próximo bloco na cache, antes que seja realmente solicitado, para 
melhorar o desempenho. 

Duas outras funções nesse arquivo estão intimamente envolvidas com o laço principal 
do sistema de arquivos. Get work (linha 24099) verifica se quaisquer funções bloqueadas 
anteriormente agora foram reanimadas. Em caso positivo, elas terão prioridade em relação 
às novas mensagens. Quando não houver nenhum trabalho interno a fazer, o sistema de 
arquivos chamará o núcleo para obter uma mensagem, na linha 24124. Pulando algumas 
linhas para frente, encontramos reply (linha 24159), que é chamada após uma chamada de 
sistema ter terminado, com êxito ou não. Ela envia uma resposta de volta para o processo 
que fez a chamada. O processo pode ter sido eliminado por um sinal, de modo que o código 
de status retornado pelo núcleo é ignorado. Nesse caso, de qualquer modo, não há nada a 
ser feito. 
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Inicialização do sistema de arquivos 


As funções que restam ser discutidas em main.c são usadas na inicialização do sistema. A 
principal é fs init, que é chamada pelo sistema de arquivos antes que ele entre em seu laço 
principal, durante a inicialização do sistema inteiro. No contexto da discussão sobre escalo- 
namento de processos, no Capítulo 2, mostramos, na Figura 2-43, o enfileiramento inicial de 
processos quando o sistema MINIX 3 inicia. O sistema de arquivos é posto em uma fila de 
prioridade mais baixa do que o gerenciador de processos, para que possamos ter certeza de 
que, no momento da inicialização, o gerenciador de processos terá uma chance de executar 
antes do sistema de arquivos. No Capítulo 4, examinamos a inicialização do gerenciador de 
processos. Quando ele constrói sua parte da tabela de processos, adicionando entradas para 
si mesmo e para todos os outros processos na imagem de inicialização, ele envia, a cada um, 
uma mensagem para o sistema de arquivos para que este possa inicializar a entrada corres- 
pondente na sua parte do sistema de arquivos. Agora, podemos ver a outra metade dessa 
interação. 

Quando o sistema de arquivos começa, ele entra em seu próprio laço, em fs init, nas 
linhas 24189 a 24202. A primeira instrução no laço é uma chamada para receive, para enviar 
uma mensagem na linha 18235, na função de inicialização pm init do gerenciador de pro- 
cesso. Cada mensagem contém um número de processo e um PID. O primeiro é usado como 
índice na tabela de processos do sistema de arquivos e o segundo é salvo no campo fp pid de 
cada entrada selecionada. Depois disso, o uid e o gid reais e efetivos do superusuário e uma 
umask ~Q (todos os bits ativos) é configurada para cada entrada selecionada. Quando é rece- 
bida uma mensagem com o valor simbólico NONE no campo de número de processo, o laço 
termina e uma mensagem é enviada de volta para o gerenciador de processos, para informar 
que tudo está OK. 

Em seguida, a inicialização do próprio sistema de arquivos é concluída. Primeiro, 
constantes importantes são testadas para ver se seus valores são válidos. Então, várias ou- 
tras funções são ativadas para inicializar a cache de blocos e a tabela de dispositivos, para 
carregar o disco de RAM, se necessário, e para carregar o superbloco do dispositivo-raiz. 
Nesse ponto, o dispositivo-raiz pode ser acessado e outro laço é feito na parte do sistema 
de arquivos da tabela de processos, para que cada processo carregado a partir da imagem 
de inicialização reconheça o diretório-raiz e o utilize como seu diretório de trabalho (linhas 
24228 a 24235). 

A primeira função chamada por fs init após terminar sua interação com o gerenciador 
de processos é buf pool, que começa na linha 24132. Ela constrói as listas encadeadas usadas 
pela cache de blocos. A Figura 5-37 mostra o estado normal da cache de blocos, no qual todos 
os blocos são vinculados no encadeamento LRU e em um encadeamento hash. Pode ser inte- 
ressante ver como a situação da Figura 5-37 acontece. Imediatamente após a cache ser inicia- 
lizada por buf pool, todos os buffers estarão no encadeamento LRU e todos serão vinculados 
no encadeamento hash 0, como se vê na Figura 5-44(a). Quando um buffer é solicitado e 
enquanto está em uso, temos a situação da Figura 5-44(b), na qual vemos que um bloco foi 
removido do encadeamento LRU e agora está em um encadeamento hash diferente. 

Normalmente, os blocos são liberados e retornados imediatamente para o encadeamen- 
to LRU. A Figura 5-44(c) mostra a situação após o bloco ter retornado para o encadeamento 
LRU. Embora não esteja mais em uso, se for necessário, ele pode ser acessado novamente, 
para fornecer os mesmos dados e, assim, é mantido no encadeamento hash. Após o sistema 
estar em funcionamento por algum tempo, pode-se esperar que quase todos os blocos tenham 
sido usados e estejam distribuídos aleatoriamente entre os diferentes encadeamentos de hash. 
Então, o encadeamento LRU será como aparece na Figura 5-37. 
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Figura 5-44 Inicialização da cache de blocos. (a) Antes que qualquer buffer tenha sido usa- 
do. (b) Depois que um bloco foi solicitado. (c) Após o bloco ter sido liberado. 


A próxima função chamada após buf pool é build dmap, que descreveremos poste- 
riormente, junto com outras funções que tratam com arquivos de dispositivo. Depois disso, 
load ram é chamada, a qual usa a próxima função que examinaremos, igetenv (linha 2641). 
Essa função recupera um identificador de dispositivo numérico do núcleo, usando o nome de 
um parâmetro de inicialização como chave. Se você tiver usado o comando syseny para ver os 
parâmetros de inicialização em um sistema MINIX 3 em funcionamento, então terá visto que 
sysenv apresenta os dispositivos numericamente, exibindo strings como 


rootdev=912 


O sistema de arquivos usa números como esse para identificar dispositivos. O número é sim- 
plesmente 256 x principal + secundário, onde principal e secundário são os números de 
dispositivo principal e secundário. Nesse exemplo, o par principal, secundário é 3, 144, que 
corresponde a /dev/c0d1p0s0, um lugar típico para instalar o MINIX 3 em um sistema com 
duas unidades de disco. 
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5.7.4 


Load ram (linha 24260) aloca espaço para um disco de RAM e carrega nele o sistema 
de arquivos raiz, se for exigido pelos parâmetros de inicialização. Ela usa igetenv para con- 
figurar os parâmetros rootdev, ramimagedev e ramsize no ambiente de inicialização (linhas 
24278 a 24280). Se os parâmetros de inicialização especificam 


rootdev = ram 


o sistema de arquivos raiz é copiado, bloco por bloco, do dispositivo nomeado por rami- 
magedev para o disco de RAM, começando com o bloco de inicialização, sem nenhuma 
interpretação das diversas estruturas de dados do sistema de arquivos. Se o parâmetro de ini- 
cialização ramsize for menor do que o tamanho de ramimagedev, o disco de RAM se tornará 
grande o suficiente para contê-lo. Se ramsize especificar um tamanho maior do que o sistema 
de arquivos do dispositivo de inicialização, o tamanho solicitado será alocado e o sistema de 
arquivos do disco de RAM será ajustado para usar o tamanho total especificado (linhas 24404 
a 24420). Essa é a única vez que o sistema de arquivos escreve um superbloco, mas, exata- 
mente como acontece na leitura de um superbloco, a cache de blocos não é usada e os dados 
são escritos diretamente no dispositivo, usando dev io. 

Dois itens são dignos de nota neste ponto. O primeiro é o código das linhas 24291 a 
24307, que trata do caso da inicialização a partir de um CD-ROM. É usada a função cdprobe, 
não discutida neste texto. Os leitores que estiverem interessados devem examinar o código 
presente em fs/cdprobe.c, que pode ser encontrado no CD-ROM ou no site web. Segundo, 
independentemente do tamanho do bloco de disco usado pelo MINIX 3 para acesso a disco 
normal, o bloco de inicialização tem sempre 1 KB e o superbloco é carregado a partir do se- 
gundo 1 KB do dispositivo de disco. Algo a mais seria complicado, pois o tamanho do bloco 
não pode ser conhecido até que o superbloco tenha sido carregado. 

Load. ram aloca espaço para um disco de RAM vazio, caso seja especificado um parâ- 
metro ramsize diferente de zero, sem uma requisição para usar o disco de RAM como sistema 
de arquivos raiz. Nesse caso, como nenhuma estrutura do sistema de arquivos é copiada, o 
dispositivo de RAM não pode ser usado como sistema de arquivos até que tenha sido iniciali- 
zado pelo comando mkfs. Como alternativa, tal disco de RAM pode ser usado para uma cache 
secundária, se suporte para isso for compilado no sistema de arquivos. 

A última função em main.c é load super (linha 24426). Ela inicializa a tabela de super- 
blocos e lê o superbloco do dispositivo-raiz. 


Operações sobre arquivos individuais 


Nesta seção, veremos as chamadas de sistema que operam sobre arquivos individualmente 
(em oposição às operações sobre diretórios). Começaremos com a maneira como os arquivos 
são criados, abertos e fechados. Depois disso, examinaremos com alguns detalhes o mecanis- 
mo por meio do qual os arquivos são lidos e escritos. Em seguida, veremos os pipes e como 
as operações sobre eles diferem das operações sobre arquivos. 


Criando, abrindo e fechando arquivos 


O arquivo open.c contém o código de seis chamadas de sistema: creat, open, mknod, mkdir, 
close e Iseek. Examinaremos creat e open juntas e, depois, veremos cada uma das outras. 
Nas versões mais antigas do UNIX, as chamadas de creat e open tinham objetivos 
distintos. Tentar abrir um arquivo que não existia gerava um erro e um novo arquivo tinha de 
ser criado com creat, que também podia ser usada para truncar um arquivo existente com o 
comprimento zero. Entretanto, a necessidade de duas chamadas distintas não existe mais em 
um sistema POSIX. Sob o padrão POSIX, a chamada de open agora permite criar um novo 
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arquivo ou truncar um arquivo antigo, de modo que a chamada de creat agora representa um 
subconjunto dos possíveis usos da chamada de open e só é necessária para compatibilidade 
com programas mais antigos. As funções que manipulam creat e open são do creat (linha 
24537) e do open (linha 24550). (Assim como no gerenciador de processos, no sistema de 
arquivos é usada a convenção de que a chamada de sistema XXX é executada pela função 
do XXX.) Abrir ou criar um arquivo envolve três passos: 


1. Encontrar o i-node (alocar e inicializar, se o arquivo for novo). 
2. Encontrar ou criar a entrada de diretório. 


3. Configurar e retornar um descritor para o arquivo. 


As chamadas de creat e de open fazem duas coisas: elas buscam o nome de um arquivo 
e depois chamam common. open, que trata das tarefas comuns às duas chamadas. 

Common open (linha 24573) começa certificando-se de que estejam disponíveis entra- 
das livres na tabela de descritores de arquivo e na tabela filp. Se a função que fez a chamada 
especificou a criação de um novo arquivo (fazendo a chamada com o bit O CREAT ativo), 
new node é chamada na linha 24594. Se entrada de diretório já existe, new. node retorna um 
ponteiro para um i-node existente; caso contrário, ela cria uma nova entrada de diretório e 
um novo i-node. Se o i-node não puder ser criado, new node configurará a variável global 
err code. Um código de erro nem sempre significa um erro. Se new node encontrar um ar- 
quivo já existente, o código de erro retornado indicará que o arquivo existe, mas, nesse caso, 
esse erro é aceitável (linha 24597). Se o bit O CREAT não for ativado, será feita uma busca 
do i-node usando um método alternativo, a função eat path em path.c, que discutiremos mais 
adiante. Nesse ponto, o importante a entender é que, se um i-node não for encontrado ou 
criado com sucesso, common. open terminará com um erro antes de chegar na linha 24606. 
Caso contrário, a execução continuará aqui, com a atribuição de um descritor de arquivo e a 
reivindicação de uma entrada na tabela filp. Depois disso, se um novo arquivo acabou de ser 
criado, as linhas 24612 a 24680 serão puladas. 

Se o arquivo não é novo, então o sistema de arquivos deve fazer um teste para ver qual 
é o tipo do arquivo, qual é seu modo etc., para determinar se ele pode ser aberto. A chamada 
para forbidden, na linha 24614, primeiro faz uma verificação geral dos bits rwx. Se for um 
arquivo regular e common open foi chamada com o bit O TRUNC ativo, ele será truncado 
para comprimento zero e forbidden será chamada novamente (linha 24620), desta vez para 
certificar-se de que o arquivo pode ser escrito. Se as permissões admitirem, wipe inode e 
rw inode serão chamadas para reinicializar o i-node e escrevê-lo no disco. Outros tipos de ar- 
quivo (diretórios, arquivos especiais e pipes nomeados) são submetidos a testes apropriados. 
No caso de um dispositivo, é feita uma chamada, na linha 24640 (usando a estrutura dmap), 
para a rotina apropriada, para abrir o dispositivo. No caso de um pipe nomeado, é feita uma 
chamada para pipe open (linha 24646) e são feitos vários testes relevantes para pipes. 

O código de common. open, assim como muitas outras funções do sistema de arquivos, 
contém uma grande quantidade de código que verifica vários erros e combinações inválidas. 
Embora não seja fascinante, esse código é fundamental para se ter um sistema de arquivos 
robusto e sem erros. Se algo der errado, o descritor de arquivo, a entrada de filp alocados an- 
teriormente e o i-node serão liberados (linhas 24683 a 24689). Nesse caso, o valor retornado 
por common open será um número negativo, indicando um erro. Se não houver problemas, 
será retornado o descritor de arquivo, um valor positivo. 

Este é um bom lugar para discutirmos com mais detalhes o funcionamento de new node 
(linha 24697), que faz a alocação do i-node e a entrada do nome de caminho no sistema de 
arquivos para chamadas de creat e open. Ela também é usada pelas chamadas de mknod e 
mkdir, que ainda serão discutidas. A instrução na linha 24711 analisa o nome de caminho (isto 
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é, o pesquisa componente por componente) até o diretório final; a chamada para advance, três 
linhas depois, tenta ver se o último componente pode ser aberto. 
Por exemplo, na chamada 


fd = creat("/usr/ast/foobar", 0755); 


last dir tenta carregar o i-node de /usr/ast/nas tabelas e retornar um ponteiro para ele. Se o 
arquivo não existir, precisaremos desse i-node em breve, para adicionar foobar no diretório. 
Todas as outras chamadas de sistema que adicionam ou excluem arquivos também usam 
last dir para primeiro abrir o último diretório do caminho. 

Se new node descobrir que o arquivo não existe, ela chamará alloc inode, na linha 
24717, para alocar e carregar um novo i-node, retornando um ponteiro para ele. Se não resta- 
rem i-nodes livres, new node falhará e retornará NIL INODE. 

Se um i-node puder ser alocado, a operação continuará na linha 24727, preenchendo 
alguns dos campos, escrevendo-o no disco e inserindo o nome de arquivo no diretório final 
(na linha 24732). Novamente, vemos que o sistema de arquivos deve constantemente verificar 
a existência de erros e, ao encontrar um, liberar cuidadosamente todos os recursos, como os 
i-nodes e blocos que está mantendo. Se precisássemos apenas preparar o MINIX 3 para entrar 
em uma situação de pânico ao ficarmos, digamos, sem i-nodes, em vez de desfazer todos os 
efeitos da chamada corrente e retornar um código de erro para o processo que fez a chamada, 
o sistema de arquivos seria consideravelmente mais simples. 

Conforme mencionado anteriormente, os pipes exigem tratamento especial. Se não 
houver pelo menos um par leitor/escritor para um pipe, pipe open (linha 24758) suspenderá 
o processo que fez a chamada. Caso contrário, cnamará release, que percorre a tabela de pro- 
cessos em busca de processos que estejam bloqueados no pipe. Se ela tiver êxito, os processos 
serão reanimados. 

A chamada de mknod é manipulada por do mknod (linha 24785). Essa função é se- 
melhante a do creat, exceto que apenas cria o i-node e estabelece uma entrada de diretório 
para ele. Na verdade, a maior parte do trabalho é feita pela chamada para new node, na linha 
24797. Se o i-node já existir, será retornado um código de erro. Esse é o mesmo código de 
erro que era um resultado aceitável de new node, quando foi chamada por common open; 
neste caso, entretanto, o código de erro é passado de volta para o processo que fez a chamada, 
o qual presumivelmente reagirá de acordo. A análise caso a caso que vimos em common open 
não é necessária aqui. 

A chamada de mkdir é manipulada pela função do mkdir (linha 24805). Assim como 
acontece com as outras chamadas de sistema que discutimos aqui, new node desempenha 
um papel importante. Ao contrário dos arquivos, os diretórios sempre têm vínculos e nunca 
estão completamente vazios, pois todo diretório deve conter duas entradas desde o momen- 
to de sua criação: As entradas “.” e “..”, que se referem ao diretório em si e ao seu diretório 
pai. O número de vínculos que um arquivo pode ter é limitado a LINK MAX (definida em 
include/limits.h como SHRT MAX, 32767 para o MINIX 3, em um sistema Intel 32 bits 
padrão). Como a referência para um diretório pai em um filho é um vínculo para o pai, a pri- 
meira coisa que do mkdir faz é ver se é possível estabelecer outro vínculo no diretório pai (li- 
nhas 24819 e 24820). Uma vez que esse teste tenha sido aprovado, new node é chamada. Se 
new node tiver êxito, então serão feitas as entradas de diretório para “.” e “..” (linhas 24841 e 
24842). Tudo isso é simples, mas poderia haver falhas (por exemplo, se o disco estiver cheio); 
portanto, para evitar confusão, foram tomadas providências para desfazer os estágios iniciais 
do processo, caso ele não possa ser concluído. 

Fechar um arquivo é mais fácil do que abrir. O trabalho é feito por do close (linha 
24865). Pipes e arquivos especiais precisam de alguma atenção, mas para arquivos regulares, 
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quase tudo que precisa ser feito é decrementar o contador filp e verificar se ele é zero, no caso 
em que o i-node será retornado com put inode. O último passo é remover todas as travas e 
reanimar todos os processos que possam estar suspensos esperando que uma trava no arquivo 
seja liberada. 

Note que retornar um i-node significa que seu contador na tabela inode é decrementado, 
para que finalmente ele possa ser removido da tabela. Essa operação não tem nada a ver com 
a liberação do i-node (isto é, ativar um bit no mapa de bits dizendo que ele está disponível). O 
i-node só será liberado quando o arquivo tiver sido removido de todos os diretórios. 

A última função em open.c é do Iseek (linha 24939). Quando é feita uma busca, essa 
função é chamada para configurar a posição do arquivo com um novo valor. Na linha 24968, 
a leitura antecipada é inibida; uma tentativa explícita de fazer uma busca em uma posição em 
um arquivo é incompatível com o acesso segiiencial. 


Lendo um arquivo 


Uma vez que um arquivo tenha sido aberto, ele pode ser lido ou escrito. Muitas funções são 
usadas durante a leitura e a escrita. Elas são encontradas no arquivo read.c. Discutiremos 
essas primeiro e depois passaremos ao arquivo seguinte, write.c, para examinarmos o código 
usado especificamente para escrita. A leitura e a escrita diferem de diversas maneiras, mas 
têm semelhanças suficientes para que de do read (linha 25030), seja exigido apenas chamar 
a função comum read write com um flag configurado como READING. Na próxima seção, 
veremos que do write é igualmente simples. 

Read write começa na linha 25038. Um código especial, nas linhas 25063 a 25066, é 
usado pelo gerenciador de processos para fazer o sistema de arquivos carregar os segmentos 
inteiros para ele em espaço de usuário. As chamadas normais são processadas a partir da li- 
nha 25068. Algumas verificações de validade aparecem a seguir (por exemplo, ler um arqui- 
vo aberto apenas para escrita) e algumas variáveis são inicializadas. As leituras de arquivos 
especiais de caractere não passam pela cache de blocos, de modo que elas são filtradas na 
linha 25122. 

Os testes nas linhas 25132 a 25145 se aplicam somente às escritas e estão relacionados 
com arquivos que podem ficar maiores do que o dispositivo pode conter ou com escritas que 
criarão uma lacuna no arquivo, escrevendo além do fim do arquivo. Conforme discutimos 
na visão geral sobre o MINIX 3, a presença de vários blocos por zona causa problemas que 
devem ser tratados explicitamente. Os pipes também são especiais e são verificados. 

O centro do mecanismo de leitura, pelo menos para arquivos regulares, é o laço que 
começa na linha 25157. Esse laço divide a requisição em trechos, cada um dos quais cabendo 
em um único bloco de disco. Um trecho começa na posição corrente e se estende até que uma 
das seguintes condições seja satisfeita: 


1. Todos os bytes foram lidos. 
2. Um limite de bloco foi encontrado. 


3. O fim do arquivo foi atingido. 


Essas regras significam que um trecho nunca exige dois blocos de disco para comportá- 
lo. A Figura 5-45 mostra três exemplos de como o tamanho do trecho é determinado, para 
tamanhos de trecho de 6, 2 e 1 bytes, respectivamente. O cálculo em si é feito nas linhas 
25159 a 25169. 

A leitura real do trecho é feita por rw. chunk. Quando o controle retorna, vários conta- 
dores e ponteiros são incrementados e a próxima iteração começa. Quando o laço termina, a 
posição do arquivo e outras variáveis podem ser atualizadas (por exemplo, ponteiros de pipe). 
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Número do byte 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 


| Bloco nt Bloco -| 


Posição corrente = 1 


ZARA | | | T™=s 


Posição corrente = 6 
Posição corrente = 9 


Figura 5-45 Três exemplos de como o primeiro tamanho de trecho é determinado para um 
arquivo de 10 bytes. O tamanho do bloco é de 8 bytes e o número de bytes solicitados é 6. O 
trecho aparece sombreado. 


Finalmente, se for solicitada leitura antecipada, o i-node e a posição a serem lidos são 
armazenados em variáveis globais para que, depois que a mensagem de resposta for enviada 
para o usuário, o sistema de arquivos possa começar a obter o próximo bloco. Em muitos 
casos, o sistema de arquivos será bloqueado, esperando pelo próximo bloco de disco, tempo 
durante o qual o processo do usuário poderá trabalhar nos dados que acabou de receber. 
Essa organização sobrepõe o processamento e a E/S e pode melhorar o desempenho subs- 
tancialmente. 

A função rw_chunk (linha 25251) está relacionada à obtenção de um i-node e de uma 
posição de arquivo, convertê-los em um número de bloco de disco físico e solicitar a transfe- 
rência desse bloco (ou de uma parte dele) para o espaço de usuário. O mapeamento da posição 
relativa do arquivo no endereço de disco físico é feito por read map, que entende a respeito 
de i-nodes e blocos indiretos. Para um arquivo regular, as variáveis b e dev, na linha 25280 e 
na linha 25281, contêm o número de bloco físico e o número do dispositivo, respectivamente. 
A chamada para get block, na linha 25303, é onde a rotina de tratamento de cache é chamada 
para encontrar o bloco, lendo-o, se necessário. Então, a chamada de rahead, na linha 25295, 
garante que o bloco seja lido na cache. 

Uma vez que tenhamos um ponteiro para o bloco, a chamada de núcleo sys vircopy, 
na linha 25317, trata da transferência da parte exigida dele para o espaço de usuário. Então, 
o bloco é liberado por put block, para que possa ser descarregado da cache posteriormente. 
(Após ser adquirido por get block, ele não estará na fila LRU e não será retornado para lá 
enquanto o contador no cabeçalho do bloco mostrar que ele está em uso, de modo que estará 
livre do despejo; put block decrementa o contador e retorna o bloco para a fila LRU quando o 
contador chega a zero.) O código da linha 25327 indica se uma operação de escrita preencheu 
o bloco. Entretanto, o valor passado para put block em n não afeta o modo como o bloco é 
colocado na fila; agora, todos os blocos são colocados no fim do encadeamento LRU. 

Read map (linha 25337) converte uma posição de arquivo lógica no número de bloco 
físico, inspecionando o i-node. Para blocos próximos do início do arquivo o suficiente para 
que caiam dentro de uma das sete primeiras zonas (aquelas exatamente no i-node), basta um 
cálculo simples para determinar qual zona é necessária e, depois, qual bloco. Para blocos 
mais adiante no arquivo, talvez um ou mais blocos indiretos precisem ser lidos. 
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Rd indir (linha 25400) é chamada para ler um bloco de indireção simples. Os comen- 
tários dessa função estão um pouco desatualizados; o código para suportar o processador 
68000 foi removido e o suporte para o sistema de arquivos V1 do MINIX não é utilizado 
e também poderia ser eliminado. Entretanto, vale notar que, se alguém quisesse adicionar 
suporte para outras versões do sistema de arquivos ou para outras plataformas onde os da- 
dos poderiam ter um formato diferente no disco, os problemas dos tipos de dados e ordens 
de byte diferentes poderiam ser relegados a esse arquivo. Se conversões confusas fossem 
necessárias, fazê-las aqui permitiria que o restante do sistema de arquivos visse dados em 
apenas uma forma. 

Read ahead (linha 25432) converte a posição lógica em um número de bloco físico, 
chama get block para certificar-se de que o bloco está na cache (ou para trazê-lo) e, então, 
retorna o bloco imediatamente. No momento, talvez não se precise do bloco, mas é desejável 
melhorar a chance de que ele esteja por perto, caso se torne necessário em breve. Note que 
read ahead é chamada apenas a partir do laço principal em main. Ela não é chamada como 
parte do processamento da chamada de sistema read. É importante perceber que a chamada 
para read ahead é realizada depois que a resposta é enviada, para que o usuário possa conti- 
nuar executando, mesmo que o sistema de arquivos tenha de esperar por um bloco de disco, 
enquanto faz a leitura antecipada. 

Read ahead em si é projetada para solicitar apenas mais um bloco. Ela chama a última 
função em read.c, rahead, para fazer o trabalho. Rahead (linha 25451) funciona de acordo 
com a teoria de que, se um pouco mais é bom, muito mais é melhor. Como os discos e ou- 
tros dispositivos de armazenamento frequentemente demoram um tempo relativamente longo 
para localizar o primeiro bloco solicitado, mas então podem ler vários blocos adjacentes de 
forma relativamente rápida, é possível ler muito mais blocos com pouco esforço adicional. 
Um pedido de busca antecipada é feito para get block, a qual prepara a cache de blocos para 
receber vários blocos de uma vez. Então, rw scattered é chamada com uma lista de blocos. 
Já discutimos isso anteriormente; lembre-se de que, quando os drivers de dispositivo são 
realmente chamados por rw. scattered, cada um fica livre para responder apenas à quantidade 
da requisição que puder manipular eficientemente. Tudo isso parece muito complicado, mas 
as complicações tornam possível acelerar significativamente os aplicativos que lêem grandes 
volumes de dados do disco. 

A Figura 5-46 mostra as relações entre algumas das principais funções envolvidas na 
leitura de um arquivo — em particular, quem chama quem. 


Escrevendo um arquivo 


O código para escrever em arquivos está em write.c. A escrita em um arquivo é semelhante 
à leitura e do write (linha 25625) apenas chama read write com o flag WRITING. Uma di- 
ferença importante entre leitura e escrita é que escrever exige a alocação de novos blocos de 
disco. Write map (linha 25635) é análoga a read map, somente que, em vez de pesquisar nú- 
meros de bloco físicos no i-node e seus blocos de indireção simples, ela insere outros novos 
(para sermos precisos, ela insere números de zona e não números de bloco). 

O código de write map é longo e detalhado porque precisa tratar de vários casos. Se 
a zona a ser inserida estiver próxima ao início do arquivo, ela é apenas inserida no i-node 
(linha 25658). 

O pior caso acontece quando um arquivo ultrapassa o tamanho que pode ser manipu- 
lado por um único bloco de indireção simples, de modo que, agora, é exigido um bloco de 
dupla indireção. Em seguida, um único bloco de indireção simples é alocado e seu endere- 
ço colocado no bloco de indireção dupla. Assim como acontece na leitura, é chamada uma 
função separada, wr indir. Se o bloco de indireção dupla for adquirido corretamente, mas o 
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Figura 5-46 Algumas das funções envolvidas na leitura de um arquivo. 


disco estiver cheio, de modo que o bloco de indireção simples não pode ser alocado, então o 
bloco de indireção dupla deverá ser retornado para evitar a corrupção do mapa de bits. 

Novamente, se pudéssemos apenas desistir e aceitar uma situação de pânico neste pon- 
to, o código seria muito mais simples. Entretanto, do ponto de vista do usuário é muito melhor 
que o fato de ficar sem espaço em disco apenas retorne um erro de write, do que o computador 
pare com um sistema de arquivos corrompido. 

Wr. indir (linha 25726) chama as rotinas de conversão, conv2 e conv4, para fazer a 
conversão de dados necessária e colocar um novo número de zona em um bloco de indireção 
simples. (Novamente, há código de sobra aqui para manipular o antigo sistema de arquivos 
V1, mas apenas o código do V2 é usado atualmente.) Lembre-se de que o nome dessa função, 
assim como os nomes de muitas outras funções que envolvem leitura e escrita, não é literal- 
mente verdadeiro. A escrita real no disco é manipulada pelas funções que mantêm a cache de 
blocos. 

A função seguinte em write.c é clear zone (linha 25747), que trata do problema do apa- 
gamento de blocos que estão repentinamente no meio de um arquivo. Isso acontece quando é 
feita uma busca além do fim de um arquivo, seguida da escrita de alguns dados. Felizmente, 
essa situação não ocorre com muita fregiiência. 

New block (linha 25787) é chamada por rw chunk quando um novo bloco é necessário. 
A Figura 5-47 mostra seis estágios sucessivos do crescimento de um arquivo sequencial. O 
tamanho do bloco é de 1 KB e o tamanho da zona é de 2 KB, nesse exemplo. 
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Figura 5-47 (a) — (f) A alocação sucessiva de blocos de 1 KB com uma zona de 2 KB. 


Número do bloco 


Na primeira vez que new. block é chamada, ela aloca a zona 12 (blocos 24 e 25). Na 
próxima vez, ela usa o bloco 25, que já foi alocado, mas ainda não está em uso. Na terceira 
chamada, a zona 20 (blocos 40 e 41) é alocada e assim por diante. Zero block (linha 25839) 
limpa um bloco, apagando seu conteúdo anterior. Esta descrição é consideravelmente mais 
longa do que o código real. 


Pipes 
Sob muitos aspectos, os pipes são semelhantes aos arquivos regulares. Nesta seção, focaliza- 
remos as diferenças. O código que vamos discutir está todo em pipe.c. 

Antes de tudo, os pipes são criados de forma diferente, pela chamada pipe, em vez da 
chamada creat. A chamada pipe é manipulada por do pipe (linha 25933). Tudo que do pipe 
faz é alocar um i-node para o pipe e retornar dois descritores de arquivo para ele. Os pipes 
pertencem ao sistema (e não ao usuário) e estão localizados no dispositivo de pipe designado 
(configurado em include/minix/config.h), o qual poderia muito bem ser um disco RAM, pois 
os dados do pipe não precisam ser preservados permanentemente. 

Ler e escrever em um pipe é ligeiramente diferente de ler e escrever em um arquivo, 
pois um pipe tem capacidade finita. Uma tentativa de escrever em um pipe que já está cheio 
fará com que o escritor seja suspenso. Analogamente, ler um pipe vazio suspenderá o leitor. 
Na verdade, um pipe tem dois ponteiros, a posição corrente (usada pelos leitores) e o tamanho 
(usado pelos escritores), para determinar de onde vem os dados ou para onde vão. 

As diversas verificações para ver se uma operação sobre um pipe é possível são rea- 
lizadas por pipe check (linha 25986). Além desses testes, que podem levar à suspensão do 
processo que fez a chamada, pipe check chama release para ver se um processo suspenso 
anteriormente, devido à falta ou ao excesso de dados, agora pode ser reanimado. Essas rea- 
nimações são feitas na linha 26017 e na linha 26052, para escritores e leitores em repouso, 
respectivamente. A escrita em um pipe quebrado (nenhum leitor) também é detectada aqui. 

O ato de suspender um processo é realizado por suspend (linha 26073). Tudo que ela 
faz é salvar os parâmetros da chamada na tabela de processos e configurar o flag dont reply 
como TRUE, para inibir a mensagem de resposta do sistema de arquivos. 

A função release (linha 26099) é chamada para verificar se um processo que foi sus- 
penso em um pipe agora pode continuar. Se ela encontrar um, chamará revive para ativar um 
flag para que o laço principal observe isso posteriormente. Essa função não é uma chamada 
de sistema, mas está listada na Figura 5-33(c) porque utiliza o mecanismo de passagem de 
mensagens. 

A última função em pipe.c é do unpause (linha 26189). Quando o gerenciador de pro- 
cessos está tentando sinalizar um processo, precisa descobrir se esse processo está pendente 
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em um pipe ou em um arquivo especial (no caso em que ele deve ser despertado com um erro 
EINTR). Como o gerenciador de processos não sabe nada sobre pipes ou arquivos especiais, 
ele envia uma mensagem para o sistema de arquivos. Essa mensagem é processada por do . 
unpause, que reanima o processo, caso ele esteja bloqueado. Assim como revive, do unpause 
tem alguma semelhança com uma chamada de sistema, embora não seja uma. 

As duas últimas funções em pipe.c, select request pipe (linha 26247) e select match. 
pipe (linha 26278), suportam a chamada select, que não será discutida aqui. 


Diretórios e caminhos 


Agora, acabamos de ver como os arquivos são lidos e escritos. Nossa próxima tarefa é ver 
como os nomes de caminho e diretórios são manipulados. 


Convertendo um caminho em um i-node 


Muitas chamadas de sistema (por exemplo, open, unlink e mount) têm nomes de caminho 
(isto é, nomes de arquivo) como parâmetro. A maioria dessas chamadas precisa buscar o i- 
node do arquivo referenciado, antes que possam começar o trabalhar na chamada em si. O 
modo como um nome de caminho é convertido em i-node é o assunto que veremos agora em 
detalhes. Já vimos o esboço geral na Figura 5-16. 

A análise de nomes de caminho é feita no arquivo path.c. A primeira função, eat path 
(linha 26327), aceita um ponteiro para um nome de caminho, o analisa, faz com que seu i- 
node seja carregado na memória e retorna um ponteiro para o i-node. Ela faz seu trabalho 
chamando last dir para chegar ao i-node do diretório final e depois chamando advance para 
obter o último componente do caminho. Se a pesquisa falha, por exemplo, porque um dos 
diretórios ao longo do caminho não existe ou existe, mas está protegido contra pesquisa, 
NIL INODE é retornado, em vez de um ponteiro para o i-node. 

Os nomes de caminho podem ser absolutos ou relativos e podem ter, arbitrariamente, 
muitos componentes, separados por barras. Essas questões são tratadas por last. dir, que co- 
meça examinando o primeiro caractere do nome do caminho para ver se ele é um caminho 
absoluto ou um caminho relativo (linha 26371). Para caminhos absolutos, rip é configurada 
para apontar para o i-node raiz; para caminhos relativos, ela é configurada para apontar para 
o i-node do diretório de trabalho corrente. 

Nesse ponto, last dir tem o nome de caminho e um ponteiro para o i-node do diretório 
onde o primeiro componente vai ser pesquisado. Agora, ela entra em um laço, na linha 26382, 
analisando o nome de caminho, componente por componente. Quando chega ao fim, ela re- 
torna um ponteiro para o último diretório. 

Get name (linha 26413) é uma função auxiliar que extrai componentes de strings. Mais 
interessante é advance (linha 26454), que recebe um ponteiro de diretório e uma string como 
parâmetros e pesquisa a string no diretório. Se encontra a string, advance retorna um ponteiro 
para seu i-node. Os detalhes da transferência entre os sistemas de arquivos montados são 
tratados aqui. 

Embora advance controle a pesquisa de string, a comparação real da string com as 
entradas de diretório é feita em search dir (linha 26535), que é o único lugar no sistema de 
arquivos onde arquivos de diretório são examinados realmente. Ela contém dois laços ani- 
nhados, um para percorrer os blocos de um diretório e outro para percorrer as entradas de um 
bloco. Search dir também é usada para inserir e excluir nomes de diretórios. A Figura 5-48 
mostra os relacionamentos entre algumas das principais funções usadas na pesquisa de nomes 
de caminho. 
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Figura 5-48 Algumas das funções usadas na pesquisa de nomes de caminho. 


Montando sistemas de arquivos 


Duas chamadas de sistema que afetam o sistema de arquivos como um todo são mount e 
umount. Elas permitem que sistemas de arquivos independentes, em diferentes dispositivos 
secundários, sejam “colados”, formando uma única árvore de atribuição de nomes integral. 
A montagem, conforme vimos na Figura 5-38, é efetivamente obtida lendo-se o i-node raiz e 
o superbloco do sistema de arquivos a ser montado e configurando-se dois ponteiros em seu 
superbloco. Um deles aponta para o i-node que está sendo montado e o outro aponta para o 
i-node raiz do sistema de arquivos montado. Esses ponteiros ligam os sistemas de arquivos. 

A configuração desses ponteiros é feita no arquivo mount.c por do mount, nas linhas 
26819 e 26820. As duas páginas de código que precedem a configuração dos ponteiros são 
quase inteiramente dedicadas à verificação de todos os erros que podem ocorrer enquanto um 
sistema de arquivos é montado, dentre eles: 


O arquivo especial dado não é um dispositivo de bloco. 

O arquivo especial é um dispositivo de bloco, mas já está montado. 

O sistema de arquivos a ser montado tem um número mágico inválido. 

O sistema de arquivos a ser montado é inválido (por exemplo, nenhum i-node). 
O arquivo em que está sendo montado não existe ou é um arquivo especial. 


Não há espaço para os mapas de bits do sistema de arquivos montado. 


CON de ouso a 


Não há espaço para o superbloco do sistema de arquivos montado. 


8. Não há espaço para o i-node raiz do sistema de arquivos montado. 


Talvez pareça inadequado ficar repetindo este ponto, mas a realidade de qualquer siste- 
ma operacional prático é que uma parte substancial do código é dedicada à execução de pe- 
quenas tarefas que não são intelectualmente muito estimulantes, mas são fundamentais para 
tornar um sistema utilizável. Se um usuário tentar montar acidentalmente um disquete errado, 
digamos, uma vez por mês, e isso levar a uma falha e a um sistema de arquivos corrompido, o 
usuário considerará o sistema não confiável, pondo a culpa no projetista e não em si mesmo. 

Uma vez, o famoso inventor Thomas Edison fez um comentário que é relevante aqui. 
Ele disse que “gênio” é 1% inspiração e 99% transpiração. A diferença entre um bom sistema 
e um sistema medíocre não é o brilho do algoritmo de escalonamento do primeiro, mas sua 
atenção em fazer todos os detalhes direito. 

Desmontar um sistema de arquivos é mais fácil do que montar — há menos coisas que 
podem dar errado. Do umount (linha 26828) é chamada para iniciar o trabalho, que é divi- 


544 


SISTEMAS OPERACIONAIS 


dido em duas partes. Do umount em si verifica se a chamada foi feita pelo superusuário, 
converte o nome em um número de dispositivo e, então, chama unmount (linha 26846), que 
completa a operação. O único problema real é garantir que nenhum processo tenha quais- 
quer arquivos ou diretórios de trabalho abertos no sistema de arquivos a ser removido. Essa 
verificação é simples: basta percorrer a tabela de i-nodes inteira para ver se algum i-node na 
memória (outro que não seja o i-node raiz) pertence ao sistema de arquivos a ser removido. 
Se houver um, a chamada umount falhará. 

A última função em mount.c é name to dev (linha 26893), que pega um nome de ca- 
minho de arquivo especial, obtém seu i-node e extrai seus números de dispositivo principal e 
secundário. Eles são armazenados no próprio i-node, no lugar onde a primeira zona normal- 
mente ficaria. Essa entrada está disponível porque os arquivos especiais não possuem zonas. 


Vinculando e desvinculando arquivos 


O próximo arquivo a considerar é link.c, que trata da vinculação e da desvinculação de ar- 
quivos. A função do link (linha 27034) é muito parecida com do mount, pois quase todo o 
código é dedicado à verificação de erros. Alguns dos possíveis erros que podem ocorrer na 
chamada 


link(file name, link name); 


estão listados a seguir: 


File name não existe ou não pode ser acessado. 
File name já tem o número máximo de vínculos. 
File name é um diretório (somente o superusuário pode criar vínculos para ele). 


Link name já existe. 


GV Adão o a E 


File name e link name estão em dispositivos diferentes. 


Se nenhum erro estiver presente, uma nova entrada de diretório será feita com a string 
link name e o número do i-node de file name. No código, name1 corresponde a file name e 
name2 corresponde a link name. A entrada real é feita por search. dir, chamada a partir de 
do link, na linha 27086. 

Arquivos e diretórios são removidos ao serem desvinculados. O trabalho das chamadas 
de sistema unlink e rmdir é feito por do unlink (linha 27104). Novamente, devem ser feitas 
várias verificações; os testes para ver se um arquivo existe e se um diretório não é um ponto 
de montagem são feitos pelo código comum em do unlink e, então, remove dir ou unlink file 
é chamada, dependendo da chamada de sistema que está sendo suportada. Discutiremos isso 
em breve. 

A outra chamada de sistema suportada em [ink.c é rename. Os usuários do UNIX estão 
familiarizados com o comando shell mv, o qual, em última análise, utiliza essa chamada; seu 
nome reflete outro aspecto da chamada. Ela não apenas pode alterar o nome de um arquivo 
dentro de um diretório, como também pode mover efetivamente o arquivo de um diretório 
para outro, e pode fazer isso de forma atômica, o que evita certas condições de corrida. O 
trabalho é feito por do rename (linha 27162). Muitas condições devem ser testadas antes que 
esse comando possa ser concluído. Dentre elas, estão: 


1. O arquivo original deve existir (linha 27177). 


2. O nome de caminho antigo não deve ser um diretório acima do novo nome de ca- 
minho na árvore de diretórios (linhas 27195 a 27212). 
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3. Nem “.” nem “..” são aceitáveis como nome antigo ou novo (linhas 27217 e 
27218). 


4. Os dois diretórios pais devem estar no mesmo dispositivo (linha 27221). 


5. Os dois diretórios pais devem permitir escrita, pesquisa e estar em um dispositivo 
gravável (linhas 27224 e 27225). 


6. Nem o nome antigo nem o novo podem ser um diretório com um sistema de arqui- 
vos montado. 


Algumas outras condições devem ser verificadas, caso o novo nome já exista. O princi- 
pal é que deve ser possível remover um arquivo já existente com o novo nome. 

No código de do rename existem alguns exemplos de decisões de projeto que foram 
tomadas para minimizar a possibilidade de haver certos problemas. Renomear um arquivo 
com um nome que já existe poderia falhar em um disco cheio (mesmo que, no final, nenhum 
espaço adicional seja usado), se o arquivo antigo não fosse removido primeiro e é isso que é 
feito nas linhas 27260 a 27266. A mesma lógica é usada na linha 27280, removendo o nome 
de arquivo antigo antes de criar um novo nome no mesmo diretório, para evitar a possibilida- 
de de que o diretório precise adquirir um bloco adicional. Entretanto, se o novo arquivo e o 
arquivo antigo vão ficar em diretórios diferentes, essa preocupação não é relevante e, na linha 
27285, um novo nome de arquivo é criado (em um diretório diferente), antes que o antigo 
seja removido, pois do ponto de vista da integridade do sistema, uma falha que deixasse dois 
nomes de arquivo apontando para um i-node seria muito menos séria do que uma falha que 
deixasse um i-node não apontado por nenhuma entrada de diretório. A probabilidade de se 
ficar sem espaço durante uma operação de renomeação é baixa e a de uma falha de sistema é 
ainda menor, mas nesses casos não custa nada estar preparado para o pior caso. 

As funções restantes em link.c suportam aquelas que já discutimos. Além disso, a pri- 
meira delas, truncate (linha 27316), é chamada a partir de vários outros lugares no sistema de 
arquivos. Ela percorre um i-node, uma zona por vez, liberando todas as zonas que encontra, 
assim como os blocos indiretos. Remove dir (linha 27375) realiza vários testes adicionais 
para garantir que o diretório pode ser removido e, então, chama unlink file (linha 27415). Se 
nenhum erro for encontrado, a entrada de diretório será limpa e a contagem de vínculos no 
i-node será reduzida por uma unidade. 


Outras chamadas de sistema 


O último grupo de chamadas de sistema é uma mistura de coisas envolvendo status, diretó- 
rios, proteção, tempo e outros serviços. 


Alterando o status de diretórios e arquivos 


O arquivo stadir.c contém o código de seis chamadas de sistema: chdir, fchdir, chroot, stat, fstat 
e fstatfs. Ao estudarmos last dir, vimos como as pesquisas de caminho começam examinando 
o primeiro caractere do caminho, para ver se é uma barra ou não. Dependendo do resultado, 
um ponteiro é então configurado para o diretório de trabalho ou para o diretório-raiz. 

Mudar de um diretório de trabalho (ou diretório-raiz) para outro é apenas uma questão 
de alterar esses dois ponteiros dentro da tabela de processos do processo que fez a chamada. 
Essas alterações são feitas por do chdir (linha 27542) e por do chroot (linha 27580). Am- 
bas fazem a verificação necessária e, então, chamam change (linha 27594), que realiza mais 
alguns testes e, em seguida, chama change into (linha 27611) para abrir o novo diretório e 
substituir o antigo. 
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Do fchdir (linha 27529) suporta fchdir, que é uma maneira alternativa de efetuar a 
mesma operação que chdir, com o argumento de chamada sendo um descritor de arquivo, 
em vez de um caminho. Ela testa se o descritor é válido e, se for, chama change into para 
realizar o trabalho. 

Em do chdir, o código nas linhas 27552 a 27570 não é executado em chamadas chdir 
feitas por processos de usuário. Ela serve especificamente para chamadas feitas pelo geren- 
ciador de processos, para mudar para o diretório de um usuário com o objetivo de tratar de 
chamadas exec. Quando um usuário tenta executar um arquivo, digamos, a.out, em seu dire- 
tório de trabalho, é mais fácil para o gerenciador de processos mudar para esse diretório do 
que tentar descobrir onde ele está. 

As duas chamadas de sistema stat e fstat são basicamente iguais, exceto pelo modo 
como o arquivo é especificado. A primeira fornece um nome de caminho, enquanto a última 
fornece o descritor de um arquivo aberto, semelhante ao que vimos para chdir e fchdir. As 
funções de nível superior, do stat (linha 27638) e do fstat (linha 27658), chamam ambas 
stat inode para fazer o trabalho. Antes de chamar stat inode, do stat abre o arquivo para 
obter seu i-node. Desse modo, tanto do stat como do fstat passam um ponteiro de i-node 
para stat inode. 

Tudo que stat inode (linha 27673) faz é extrair informações do i-node e copiá-las em 
um buffer. O buffer deve ser copiado explicitamente em espaço de usuário, por uma chamada 
de núcleo sys datacopy, nas linhas 27713 e 27714, pois é grande demais para caber em uma 
mensagem. 

Finalmente, chegamos a do fstatfs (linha 27721). Fstatfs não é uma chamada do PO- 
SIX, embora o POSIX defina uma chamada fstatvfs semelhante, que retorna uma estrutura de 
dados muito maior. A função fstatfs do MINIX 3 retorna apenas uma parte das informações, 
o tamanho de bloco de um sistema de arquivos. O protótipo da chamada é 


- PROTOTYPE( int fstatfs, (int fd, struct statfs *st) ): 
A estrutura statfs que ela usa é simples e pode ser exibida em uma única linha: 
struct statfs (off tf bsize; /* tamanho de bloco do sistema de arquivos */ }; 


Essas definições estão em include/sys/statfs.h, que não está listado no Apêndice B. 


Proteção 


O mecanismo de proteção do MINIX 3 usa os bits rwx. Três conjuntos de bits estão presentes 
para cada arquivo: para o proprietário, para seu grupo e para outros. Os bits são configurados 
pela chamada de sistema chmod, que é executada por do chmod, no arquivo protect.c (linha 
27824). Após a realização de uma série de verificações de validade, o modo é alterado na 
linha 27850. 

A chamada de sistema chown é semelhante a chmod no sentido de que ambas alteram 
um campo de i-node interno em algum arquivo. A implementação também é semelhante, 
embora do chown (linha 27862) possa ser usada apenas pelo superusuário para mudar o pro- 
prietário. Os usuários normais podem usar essa chamada para mudar o grupo de seus próprios 
arquivos. 

A chamada de sistema umask permite que o usuário configure uma máscara (arma- 
zenada na tabela de processos), a qual, então, mascara bits nas chamadas de sistema creat 
subsegiientes. A implementação completa seria apenas uma instrução, na linha 27907, exceto 
que a chamada deve retornar como resultado o valor antigo da máscara. Essa carga adicional 
triplica o número de linhas de código exigidas (linhas 27906 a 27908). 
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5.7.7 


A chamada de sistema access torna possível para um processo descobrir se ele pode 
acessar um arquivo de uma maneira especificada (por exemplo, para leitura). Ela é implemen- 
tada por do access (linha 27914), que busca o i-node do arquivo e chama a função interna 
forbidden (linha 27938) para ver se o acesso é proibido. Forbidden verifica o uid e o gid, 
assim como as informações presentes no i-node. Dependendo do que encontra, ela seleciona 
um dos três grupos rwx e verifica se o acesso é permitido ou proibido. 

Read only (linha 27999) é uma pequena função interna que informa se o sistema de 
arquivos localizado em seu parâmetro de i-node está montado somente para leitura ou para 
leitura e escrita. É necessário impedir escritas em sistemas de arquivos montados somente 
para leitura. 


A interface de dispositivo de E/S 


Conforme mencionamos mais de uma vez, um objetivo de projeto foi tornar o MINIX 3 um 
sistema operacional mais robusto, fazendo todos os drivers de dispositivo serem executados 
como processos em espaço de usuário, sem acesso direto às estruturas de dados do núcleo ou 
ao código do núcleo. A principal vantagem dessa estratégia é que um driver de dispositivo 
defeituoso não fará o sistema inteiro falhar, mas existem algumas outras implicações. Uma 
delas é que os drivers de dispositivo que não são necessários na inicialização podem ser 
executados a qualquer momento, depois que a inicialização estiver concluída. Isso também 
implica que um driver de dispositivo pode ser parado, reiniciado ou substituído em qualquer 
instante por um outro driver para o mesmo dispositivo, enquanto o sistema está em execução. 
Essa flexibilidade está sujeita, é claro, a algumas restrições — você não pode iniciar vários 
drivers para o mesmo dispositivo. Entretanto, se o driver de disco rígido falhar, ele poderá ser 
reiniciado a partir de uma cópia no disco de RAM. 

Os drivers de dispositivo do MINIX 3 são acessados a partir do sistema de arquivos. 
Em resposta às requisições de E/S do usuário, o sistema de arquivos envia mensagens para os 
drivers de dispositivo em espaço de usuário. A tabela dmap tem uma entrada para cada tipo 
de dispositivo principal possível. Ela fornece o mapeamento entre o número de dispositivo 
principal e o driver de dispositivo correspondente. Os próximos dois arquivos que considera- 
remos lidam com a tabela dmap. A tabela em si é declarada em dmap.c. Esse arquivo também 
suporta a inicialização da tabela e uma nova chamada de sistema, devctl, que se destina a 
suportar a inicialização, a parada e a reinicialização de drivers de dispositivo. Depois disso, 
veremos device.c, que suporta operações de tempo de execução normais sobre dispositivos, 
como open, close, read, write e ioctl. 

Quando um dispositivo é aberto, fechado, lido ou escrito, dmap fornece o nome da 
função a ser chamada para manipular a operação. Todas essas funções estão localizadas no 
espaço de endereçamento do sistema de arquivos. Muitas delas não fazem nada, mas algumas 
chamam um driver de dispositivo para solicitar a E/S real. O número de processo correspon- 
dente a cada dispositivo principal também é fornecido pela tabela. 

Quando um novo dispositivo principal é adicionado no MINIX 3, uma linha deve ser 
acrescentada nessa tabela, informando qual ação, se houver, será executada quando o dispo- 
sitivo for aberto, fechado, lido ou escrito. Como um exemplo simples, se uma unidade de fita 
fosse adicionada no MINIX 3, quando seu arquivo especial fosse aberto, a função na tabela 
poderia verificar se a unidade de fita já está em uso. 

Dmap.c começa com uma definição de macro, DT (linhas 28115 a 28117), que é usa- 
da para inicializar a tabela dmap. Essa macro torna mais fácil adicionar um novo driver de 
dispositivo ao se reconfigurar o MINIX 3. Os elementos da tabela dmap são definidos em 
include/minix/dmap.h; cada elemento consiste em um ponteiro para uma função a ser chama- 
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da em uma operação open ou close, outro ponteiro para uma função a ser chamada em uma 
operação read ou write, um número de processo (um índice na tabela de processos e não um 
PID) e um conjunto de flags. A tabela real é um array desses elementos, declarado na linha 
28132. Essa tabela está globalmente disponível dentro do servidor de arquivos. O tamanho 
da tabela é NR DEVICES, que é 32 na versão do MINIX 3 descrita aqui e quase duas vezes 
maior do que o necessário para o número de dispositivos correntemente suportados. Feliz- 
mente, o comportamento da linguagem C, de configurar todas as variáveis não inicializadas 
como zero, garantirá que nenhuma informação espúria apareça em entradas não utilizadas. 

Após a declaração de dmap está uma declaração PRIVATE de init dmap. Ela é definida 
por um array de macros DT, uma para cada dispositivo principal possível. Cada uma dessas 
macros se expande, no momento da compilação, para inicializar uma entrada no conjun- 
to global. Uma olhada em algumas das macros ajudará a entender como elas são usadas. 
Init dmap[1] define a entrada do driver de memória, que é o dispositivo principal 1. A macro 
é como segue: 


DT(1, gen opcl, gen io, MEM PROC NR,0) 


O driver de memória está sempre presente e é carregado com a imagem de inicialização do 
sistema. O valor “1” como primeiro parâmetro significa que esse driver deve estar presente. 
Nesse caso, um ponteiro para gen opcl será inserido como a função a ser chamada para abrir 
ou fechar e um ponteiro para gen io será inserido para especificar a função a ser chamada 
para ler ou escrever; MEM PROC NR indica qual entrada na tabela de processos o driver de 
memória utiliza e “0” significa que nenhum flag está ativo. Agora, veja a entrada seguinte, 
init dmap/2]. Essa é a entrada para o driver de disquete e é como segue: 


DT(0, no dev, 0,0, DMAP MUTABLE) 


O primeiro “0” indica que essa entrada é para um driver que não precisa estar na imagem 
de inicialização. O padrão para o primeiro campo de ponteiro especifica uma chamada para 
no dev, em uma tentativa de abrir o dispositivo. Essa função retorna o erro ENODEV, “dis- 
positivo inexistente”, para o processo que fez a chamada. Os dois zeros seguintes também 
são padrões: como o dispositivo não pode ser aberto, não há necessidade de especificar uma 
função a ser chamada para fazer E/S e um zero na entrada da tabela de processos é interpreta- 
do como nenhum processo especificado. O significado do flag DMAP MUTABLE é que são 
permitidas alterações nessa entrada. (Note que a ausência desse flag para a entrada do driver 
de memória significa que sua entrada não pode ser alterada após a inicialização.) O MINIX 
3 pode ser configurado com ou sem um driver de disquete na imagem de inicialização. Se o 
driver de disquete estiver na imagem de inicialização e for especificado por um parâmetro 
de inicialização label=FLOPPY para ser o dispositivo de disco padrão, essa entrada será 
alterada quando o sistema de arquivos iniciar. Se o driver de disquete não estiver na imagem 
de inicialização ou se estiver na imagem, mas não for especificado para ser o dispositivo de 
disco padrão, esse campo não será alterado quando o sistema de arquivos iniciar. Entretanto, 
ainda é possível que o driver de disquete seja ativado posteriormente. Normalmente, isso é 
feito pelo script /etc/rc, executado quando init é executado. 

Do devctl (linha 28157) é a primeira função executada para atender uma chamada devcil. 
A versão corrente é muito simples e reconhece duas requisições, DEV MAPe DEV UNMAP; 
este último retorna o erro ENOSYS, que significa “função não implementada”. Obviamente, 
isso é provisório. No caso de DEV MAP, é chamada a função seguinte, map driver. 

Pode ser útil descrever como a chamada devctl é usada e os planos para seu uso no fu- 
turo. Um processo servidor, o servidor de reencarnação (RS), é usado no MINIX 3 para su- 
portar a inicialização de servidores e drivers em espaço de usuário após o sistema operacional 
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estar pronto e funcionando. A interface para o servidor de reencarnação é o utilitário service 
e exemplos de seu uso podem ser vistos em /etc/rc. Um exemplo é 


service up /sbin/floppy —dev /dev/fdo 


Essa ação resulta no servidor de reencarnação fazendo uma chamada devctl para iniciar o bi- 
nário /sbin/floppy como driver de dispositivo para o arquivo especial de dispositivo /dev/fd0. 
Para fazer isso, o servidor de reencarnação executa (com exec) o binário especificado, mas 
ativa um flag que o impede de executar até que tenha sido transformado em um processo de 
sistema. Uma vez que o processo esteja na memória e seu número de entrada na tabela de 
processos seja conhecido, é determinado o número de dispositivo principal do dispositivo es- 
pecificado. Então, essa informação é incluída em uma mensagem para o servidor de arquivos 
que solicitou a operação DEV MAP de devctl. Do ponto de vista da inicialização da interface 
de E/S, essa é a parte mais importante da tarefa do servidor de reencarnação. Para não faltar 
nada, mencionaremos também que, para completar a inicialização do driver de dispositivo, o 
servidor de reencarnação também faz uma chamada sys privctl para que a tarefa de sistema 
inicialize a entrada da tabela priv do processo do driver e permita que ele execute. Lembre- 
se, do Capítulo 2, que uma entrada dedicada da tabela priv é o que transforma um processo 
normal do espaço de usuário em um processo de sistema. 

O servidor de reencarnação é novo e na versão do MINIX 3 descrita aqui ele ainda é 
rudimentar. Os planos para as versões futuras do MINIX 3 incluem um servidor de reencar- 
nação mais poderoso, que poderá parar e reiniciar drivers, além de iniciá-los. Ele também 
poderá monitorar drivers e reiniciá-los automaticamente, caso surjam problemas. Consulte o 
site web (www.minix3.org) e o newsgroup (comp.os.minix) para saber a situação atual. 

Continuando com dmap.c, a função map driver começa na linha 281778. Sua operação 
é simples. Se o flag DMAP MUTABLE estiver ativo para a entrada na tabela dmap, valores 
apropriados serão escritos em cada entrada. Estão disponíveis três variantes diferentes da 
função para tratar da abertura e do fechamento do dispositivo; uma delas é selecionada por 
um parâmetro style, passado na mensagem do servidor de reencarnação para o sistema de ar- 
quivos (linhas 28204 a 28206). Note que dmap flags não é alterado. Se a entrada foi marcada 
originalmente como DMAP MUTABLE, ela mantém esse status após a chamada devctl. 

A terceira função em dmap.c é build map. Ela é chamada por fs init quando o sistema 
de arquivos é iniciado pela primeira vez, antes de entrar em seu laço principal. Ela começa 
fazendo um laço por todas as entradas da tabela init dmap local e copiando as macros ex- 
pandidas na tabela dmap global, para cada entrada que não tenha no dev especificado como 
o membro dmap opcl. Isso inicializa corretamente essas entradas. Caso contrário, os valores 
padrão de um driver não inicializado são configurados no local, em dmap. O restante de 
build map é mais interessante. Uma imagem de inicialização pode ser construída com vá- 
rios drivers de dispositivo de disco. Por padrão, os drivers at wini, bios. wini e floppy são 
adicionados na imagem de inicialização por Makefile em src/tools/. Um rótulo é adicionado 
para cada um deles e um item label= nos parâmetros de inicialização determina qual será 
realmente carregado na imagem e ativado como driver de disco padrão. As chamadas de 
env get param na linha 28248 e na linha 28250 usam rotinas de biblioteca que, em última 
análise, utilizam a chamada de núcleo sys getinfo para obter as strings de parâmetro de ini- 
cialização label e controller. Finalmente, build map é chamada na linha 28267, para modi- 
ficar a entrada em dmap correspondente ao dispositivo de inicialização. O principal aqui é a 
configuração do número do processo como DRVR PROC NR, que é a entrada 6 na tabela de 
processos. Essa entrada é mágica; o driver que está nessa entrada é o padrão. 

Agora, chegamos ao arquivo device.c, que contém as funções necessárias para E/S de 
dispositivo no momento da execução. 
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A primeira é dev open (linha 28334). Ela é chamada por outras partes do sistema de 
arquivos, mais frequentemente a partir de common open em main.c, quando é determinado 
que uma operação open está acessando um arquivo especial de dispositivo, mas também a 
partir de load ram e de do mount. Seu funcionamento é típico de várias funções que veremos 
aqui. Ela determina o número de dispositivo principal, verifica se é válido, então o utiliza para 
configurar um ponteiro para uma entrada na tabela dmap e, depois, faz uma chamada para a 
função apontada nessa entrada, na linha 28349: 


r = (*dp->dmap opcl)(DEV OPEN, dev, proc, flags) 


No caso de uma unidade de disco, a função chamada será gen opcl, no caso de um dispositi- 
vo de terminal, será tty opcl. Se for recebido o código de retorno SUSPEND, há um problema 
sério; uma chamada open não deve falhar dessa maneira. 

A chamada seguinte, dev close (linha 28357), é mais simples. Não se espera que seja 
feita uma chamada para um dispositivo inválido e nenhum dano será causado se uma opera- 
ção de fechamento falhar; portanto, o código é mais curto do que este texto que o está descre- 
vendo — apenas uma linha que terminará chamando a mesma função * opcl que a chamada 
de dev open, quando o dispositivo foi aberto. 

Quando o sistema de arquivos recebe uma mensagem de notificação de um driver de 
dispositivo, dev status (linha 28366) é chamada. Uma notificação significa que ocorreu um 
evento e essa função é responsável por descobrir que tipo de evento ocorreu e iniciar a ação 
apropriada. A origem da notificação é especificada como um número de processo; portanto, 
o primeiro passo é pesquisar a tabela dmap para encontrar uma entrada que corresponda ao 
processo que está sendo notificado (linhas 18371 a 18373). É possível que a notificação tenha 
sido falsificada; assim, não será um erro se nenhuma entrada correspondente for encontrada 
e dev status retornar sem encontrar uma correspondência. Se for encontrada uma corres- 
pondência, entra-se no laço das linhas 28378 a 28398. Em cada iteração, uma mensagem 
é enviada para o processo de driver que está solicitando seu status. Três tipos de respostas 
possíveis são esperados. Uma mensagem DEV REVIVE pode ser recebida se o processo que 
originalmente solicitou a E/S foi suspenso anteriormente. Nesse caso, revive (em pipe.c, linha 
26146) será chamada. Uma mensagem DEV JO READY pode ser recebida se uma chamada 
select tiver sido feita no dispositivo. Finalmente, uma mensagem DEV NO STATUS pode 
ser recebida e, na verdade, é esperada, mas possivelmente não até que um dos dois primeiros 
tipos de mensagem (ou ambos) sejam recebidos. Por isso, a variável get more é usada para 
fazer o laço se repetir até que a mensagem DEV NO STATUS seja recebida. 

Quando a E/S de dispositivo real é necessária, dev io (linha 28406) é chamada a 
partir de read write (linha 25124) para tratar de arquivos especiais de caractere e a partir 
de rw. block (linha 22661) para tratar de arquivos especiais de bloco. Ela constrói uma 
mensagem padrão (veja a Figura 3-17) e a envia para o driver de dispositivo especificado, 
chamando gen io ou ctty io, conforme determinado no campo dp->dmap driver da tabela 
dmap. Enquanto dev io está esperando uma resposta do driver, o sistema de arquivos espe- 
ra. Ele não internamente multiprogramado. Normalmente, essas esperas são muito curtas 
(por exemplo, 50 ms). Mas é possível que nenhum dado esteja disponível — isso é especial- 
mente provável se os dados foram solicitados a partir de um dispositivo de terminal. Nesse 
caso, a mensagem de resposta pode indicar SUSPEND, para suspender temporariamente o 
aplicativo que fez a chamada, mas permitir que o sistema de arquivos continue. 

A função gen opcl (linha 28455) é chamada para dispositivos de disco, sejam disque- 
tes, discos rígidos ou dispositivos baseados na memória. Uma mensagem é construída e, 
assim como acontece na leitura e na escrita, a tabela dmap é usada para determinar se gen io 
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ou ctty io será utilizada para enviar a mensagem para o processo de driver do dispositivo. 
Gen opcl também é usada para fechar os mesmos dispositivos. 

Para abrir um dispositivo de terminal, tty opcl (linha 28482) é chamada. Ela chama 
gen opcl, possivelmente após modificar os flags, e se a chamada fizer o tty se tornar o tty de 
controle do processo ativo, isso será registrado na entrada fp tty da tabela de processos desse 
processo. 

O dispositivo /dev/tty é uma ficção que não corresponde a nenhum dispositivo em par- 
ticular. Essa é uma designação “mágica” que um usuário interativo pode usar para se referir 
ao seu próprio terminal, independente do terminal físico que esteja realmente em uso. Para 
abrir ou fechar /dev/tty, é feita uma chamada para ctty opcl (linha 28518). Ela determina se a 
entrada fp tty da tabela de processos do processo corrente foi realmente modificada por uma 
chamada de ctty opcl anterior, para indicar um tty de controle. 

A chamada de sistema setsid exige algum trabalho por parte do sistema de arquivos e 
isso é feito por do setsid (linha 28534). Ela modifica a entrada da tabela de processos do pro- 
cesso corrente para registrar que ele é um líder de sessão e não possui processo de controle. 

Uma chamada de sistema, ioctl, é manipulada principalmente em device.c. Essa cha- 
mada foi colocada aqui porque está intimamente ligada à interface do driver de dispositivo. 
Quando uma chamada ioctl é feita, do ioctl (linha 28554) é executada para construir uma 
mensagem e enviá-la para o driver de dispositivo correto. 

Para controlar dispositivos de terminal, uma das funções declaradas em include/termios.h 
deve ser usada em programas escritos para serem compatíveis com o padrão POSIX. A biblio- 
teca C transformará essas funções em chamadas ioctl. Para outros dispositivos, que não os 
terminais, ioctl é usada para diversas operações, muitas das quais foram descritas no Capí- 
tulo 3. 

A próxima função, gen io (linha 28575), é o “burro de carga” real desse arquivo. Seja 
a operação em um dispositivo open ou close, read ou write, ou ioctl, essa função é chamada 
para completar o trabalho. Como /dev/tty não é um dispositivo físico, quando uma mensagem 
que se refere a ele precisa ser enviada, a função seguinte, ctty io (linha 28652), encontra o 
dispositivo principal e secundário corretos e os substitui na mensagem, antes de transmiti- 
la. A chamada é feita usando a entrada de dmap do dispositivo físico que está realmente em 
uso. Conforme o MINIX 3 está configurado correntemente, resultará em uma chamada para 
gen io. 

A função no dev (linha 28677) é chamada a partir de entradas na tabela para as quais 
não existe um dispositivo; por exemplo, quando um dispositivo de rede é referenciado em 
uma máquina sem suporte para rede. Ela retorna o status ENODEV. Isso impede falhas quan- 
do dispositivos inexistentes são acessados. 

A última função em device.c é clone opcl (linha 28691). Alguns dispositivos preci- 
sam de processamento especial na abertura. Um dispositivo assim é “clonado”; isto é, no 
caso de uma abertura bem-sucedida, ele é substituído por um novo dispositivo com um 
novo número de dispositivo secundário exclusivo. No MINIX 3, conforme descrito aqui, 
essa capacidade não é usada. Entretanto, ela é usada quando a interligação em rede está 
ativada. Naturalmente, um dispositivo que precisar disso terá uma entrada na tabela dmap 
especificando clone opcl no campo dmap opcl. Isso é feito por uma chamada do servidor 
de reencarnação que especifica STYLE CLONE. Quando clone opcl abre um dispositivo, 
a operação começa exatamente da mesma maneira que em gen opcl, mas, no retorno, um 
novo número de dispositivo secundário pode ser retornado no campo REP STATUS da men- 
sagem de resposta. Se assim for, um arquivo temporário será criado, caso seja possível 
alocar um novo i-node. Não é criada uma entrada de diretório visível. Isso não é necessário, 
pois o arquivo já está aberto. 
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5.7.8 


Tempo 


Associados a cada arquivo existem três números de 32 bits relacionados ao tempo. Dois 
deles registram os tempos em que o arquivo foi acessado e modificado pela última vez. O 
terceiro registra quando o status do i-node em si foi alterado pela última vez. Esse tempo 
muda para todo acesso a um arquivo, exceto para uma operação read ou exec. Esses tempos 
são mantidos no i-node. Com a chamada de sistema utime, os tempos de acesso e modifi- 
cação podem ser configurados pelo proprietário do arquivo ou pelo superusuário. A função 
do utime (linha 28818) no arquivo time.c executa a chamada de sistema buscando o i-node 
e armazenando o tempo nele. Na linha 28848, são zerados os flags que indicam que uma 
atualização de tempo é necessária, para que o sistema não faça uma chamada dispendiosa e 
redundante para clock time. 

Conforme vimos no capítulo anterior, o tempo real é determinado pela adição do tempo 
decorrido desde que o sistema foi iniciado (mantido pela tarefa de relógio) no tempo real 
quando a inicialização ocorreu. A chamada de sistema stime retorna o tempo real. A maior 
parte de seu trabalho é feita pelo gerenciador de processos, mas o sistema de arquivos tam- 
bém mantém um registro do tempo de inicialização em uma variável global, boottime. O ge- 
renciador de processos envia uma mensagem para o sistema de arquivos quando é feita uma 
chamada stime. A função do stime do sistema de arquivos (linha 28859) atualiza boottime a 
partir dessa mensagem. 


Suporte adicional para chamadas de sistema 


Vários arquivos não estão listados no Apêndice B, mas são exigidos para compilar um sistema 
funcional. Nesta seção, examinaremos alguns arquivos que suportam chamadas de sistema 
adicionais. Na próxima seção, mencionaremos os arquivos e as funções que fornecem suporte 
mais geral para o sistema de arquivos. 

O arquivo misc.c contém funções para algumas chamadas de sistema e de núcleo que 
não se encaixam em nenhum outro lugar. 

Do getsysinfo é uma interface para a chamada de núcleo sys datacopy. Ela se destina a 
suportar o servidor de informações para propósitos de depuração. Essa interface permite que 
o servidor de informações solicite uma cópia das estruturas de dados do sistema de arquivos 
para que possa exibi-las para o usuário. 

A chamada de sistema dup duplica um descritor de arquivo. Em outras palavras, ela cria 
um novo descritor de arquivo que aponta para o mesmo arquivo que seu argumento. A chama- 
da tem uma variante, dup2. As duas versões da chamada são manipuladas por do dup. Essa 
função foi incluída no MINIX 3 para suportar programas binários antigos. As duas chamadas 
são obsoletas. A versão atual da biblioteca C do MINIX 3 acionará a chamada de sistema 
fentl, quando uma dessas duas for encontrada em um arquivo-fonte em C. 

Fentl, manipulada por do fcntl, é a maneira preferida para solicitar operações sobre 
um arquivo aberto. Os serviços são solicitados usando-se os flags definidos pelo POSIX, 
descritos na Figura 5-49. A chamada é ativada com um descritor de arquivo, um código de 
operação e argumentos adicionais, conforme for necessário para a requisição em particular. 
Por exemplo, a equivalente da antiga chamada 


dup2(fd, fd2); 
seria 


fenti(fd, F DUPFD, fd2); 
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Operação Descrição 
F DUPFD Duplica um descritor de arquivo 
F GETFD Obtém o flag close-on-exec (fechar ao executar) 
F SETFD Configura o flag close-on-exec (fechar ao executar) 


F GETFL Obtém flags de status do arquivo 
F SETFL Configura flags de status do arquivo 


F GETLK Obtém status do travamento de um arquivo 


F SETLK Configura trava de leitura/escrita em um arquivo 


F SETLKW | Configura trava de escrita em um arquivo 


Figura 5-49 Os parâmetros de operação do POSIX para a chamada de sistema FCNTL. 


Vários dessas operações configuram ou lêem um flag; o código consiste em apenas poucas 
linhas. Por exemplo, uma requisição com F SETFD ativa um bit que obriga o fechamento de 
um arquivo quando seu processo proprietário executa uma operação exec. Uma requisição 
a F GETFD é usada para determinar se um arquivo deve ser fechado quando for feita uma 
chamada exec. F_SETFL e F GETFL permitem a configuração de flags para indicar que um 
arquivo em particular está disponível no modo de forma não bloqueante ou para operações 
de append. 

Do fcntl também manipula o travamento de arquivos. Uma chamada com o comando 
F GETLK, F SETLK ou F SETLKW especificado é transformada em uma chamada para 
lock op, discutida em uma seção anterior. 

A chamada de sistema seguinte é sync, que copia todos os blocos e i-nodes modificados 
desde que foram carregados de volta no disco. A chamada é processada por do sync. Ela 
simplesmente pesquisa todas as tabelas, procurando por entradas sujas. Os i-nodes devem ser 
processados primeiro, pois rw inode deixa seus resultados na cache de blocos. Após todos 
os i-nodes sujos serem escrito na cache de blocos, então, todos os blocos sujos são escritos 
no disco. 

As chamadas de sistema fork, exec, exit e set são, na realidade, chamadas do gerencia- 
dor de processos, mas os resultados precisam ser postados aqui também. Quando um pro- 
cesso faz um fork, é fundamental que o núcleo, o gerenciador de processos e o sistema de 
arquivos saibam todos a respeito disso. Essas “chamadas de sistema” não são provenientes de 
processos do usuário, mas do gerenciador de processos. Do fork, do exit e do set registram 
as informações relevantes na parte do sistema de arquivos da tabela de processos. Do exec 
pesquisa e fecha (usando do close) todos os arquivos marcados para serem encerrados ao 
executar. 

A última função em misc.c não é realmente uma chamada de sistema, mas é tratada 
como se fosse. Do revive é chamada quando um driver de dispositivo que anteriormente foi 
incapaz de concluir o trabalho solicitado pelo sistema de arquivos (como o fornecimento de 
dados de entrada para um processo de usuário), agora conseguiu. Então, o sistema de arqui- 
vos reanima o processo e envia a ele a mensagem de resposta. 

Uma chamada de sistema merece um arquivo de cabeçalho, assim como um arquivo- 
fonte em C para suportá-la. Select.h e select.c fornecem suporte para a chamada de sistema 
select. Select é usada quando um único processo precisa lidar com vários fluxos de E/S, 
como, por exemplo, um programa de comunicação ou de rede. Descrevê-la em detalhes está 
fora dos objetivos deste livro. 
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5.7.10 


Utilitários do sistema de arquivos 


O sistema de arquivos contém algumas funções de propósito geral que são usadas em vários 
lugares. Elas foram reunidas no arquivo utility.c. 

Clock time envia mensagens para a tarefa de sistema para descobrir qual é o tempo real 
corrente. 

Fetch name é necessária porque muitas chamadas de sistema têm um nome de arquivo 
como parâmetro. Se o nome de arquivo é curto, ele é incluído na mensagem do usuário para o 
sistema de arquivos. Se ele é longo, um ponteiro para o nome no espaço de usuário é colocado 
na mensagem. Fetch name verifica os dois casos e, de um modo ou de outro, obtém o nome. 

Duas funções aqui tratam de classes de erros gerais. No sys é a rotina de tratamento de 
erro chamada quando o sistema de arquivos recebe uma chamada de sistema que não é uma 
das suas. Panic imprime uma mensagem e diz ao núcleo para que “jogue a toalha” quando 
algo catastrófico acontecer. Funções semelhantes podem ser encontradas em pm/utility.c, no 
diretório de código-fonte do gerenciador de processos. 

As duas últimas funções, conv2 e conv4, existem para ajudar o MINIX 3 a tratar do 
problema das diferenças na ordem de byte entre diferentes famílias de CPU. Essas rotinas são 
chamadas ao se ler ou escrever em uma estrutura de dados de disco, como um i-node ou um 
mapa de bits. A ordem de byte no sistema que criou o disco é registrada no superbloco. Se 
ela for diferente da ordem usada pelo processador local, a ordem será trocada. O restante do 
sistema de arquivos não precisa saber nada sobre a ordem de byte no disco. 

Finalmente, existem dois outros arquivos que fornecem serviços auxiliares específicos 
para o gerenciador de arquivos. O sistema de arquivos pode pedir à tarefa de sistema para que 
configure um alarme para ele, mas se precisar de mais de um temporizador, poderá manter 
sua própria lista encadeada de temporizadores, semelhante ao que vimos para o gerenciador 
de processos no capítulo anterior. O arquivo timers.c fornece esse suporte para o sistema de 
arquivos. Finalmente, o MINIX 3 implementa uma maneira única de usar um CD-ROM, que 
oculta um disco MINIX 3 simulado, com várias partições em um CD-ROM, e permite inicia- 
lizar um sistema MINIX 3 ativo a partir de um CD-ROM. Os arquivos do MINIX 3 não são 
visíveis para os sistemas operacionais que suportam apenas formatos de arquivo de CD-ROM 
padrão. O arquivo cdprobe.c é usado no momento da inicialização para localizar um disposi- 
tivo de CD-ROM e os arquivos nele contidos, necessários para iniciar o MINIX 3. 


Outros componentes do MINIX 3 


O gerenciador de processos, discutido no capítulo anterior, e o sistema de arquivos, discutido 
neste capítulo, são servidores em espaço de usuário que fornecem suporte que, em um sis- 
tema operacional de projeto convencional, seria integrado em um núcleo monolítico. Entre- 
tanto, eles não são os únicos processos servidores em um sistema MINIX 3. Existem outros 
processos em espaço de usuário que possuem privilégios de sistema e devem ser considerados 
como parte do sistema operacional. Não temos espaço suficiente neste livro para discutirmos 
seus detalhes internos, mas devemos pelo menos mencioná-los aqui. 

Um deles já foi mencionado neste capítulo. Trata-se do servidor de reencarnação, RS, que 
pode iniciar um processo normal e transformá-lo em um processo de sistema. Ele é usado na 
versão corrente do MINIX 3 para ativar drivers de dispositivo que não fazem parte da imagem 
de inicialização do sistema. Nas versões futuras, ele também poderá parar e reiniciar drivers e, 
na verdade, monitorar drivers, parando-os e reiniciando-os automaticamente, caso pareçam es- 
tar com defeito. O código-fonte do servidor de reencarnação está no diretório src/servers/rs/. 
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Outro servidor que foi mencionado de passagem é o servidor de informações (SD. Ele 
é usado para gerar os core dumps que podem ser disparados pelo pressionar das teclas de 
função em um teclado estilo PC. O código-fonte do servidor de informações está no diretório 
src/servers/is/. 

O servidor de informações e os servidores de reencarnação são programas relativa- 
mente pequenos. Existe um terceiro servidor opcional, o servidor de rede ou INET. Ele é 
bem grande. A imagem do programa INET no disco tem um tamanho comparável à ima- 
gem de inicialização do MINIX 3. Ele é iniciado pelo servidor de reencarnação de maneira 
muito parecida com os drivers de dispositivo. O código-fonte de inet está no diretório 
src/servers/inet/. 

Finalmente, mencionaremos um outro componente do sistema que é considerado um 
driver de dispositivo e não um servidor. Trata-se do driver de log. Com tantos componentes 
diferentes do sistema operacional sendo executados como processos independentes, é dese- 
Jável fornecer uma maneira padronizada de manipular mensagens de diagnóstico, de alerta 
e de erro. A solução do MINIX 3 é ter um driver de dispositivo para um pseudo-dispositivo 
conhecido como /dev/klog, o qual pode receber mensagens e escrevê-las em um arquivo. O 
código-fonte do driver de log está no diretório src/drivers/log/. 


RESUMO 


Quando visto de fora, um sistema de arquivos é uma coleção de arquivos e diretórios, mais 
as operações sobre eles. Os arquivos podem ser lidos e escritos, os diretórios podem ser 
criados e destruídos, e os arquivos podem ser movidos de um diretório para outro. A maioria 
dos sistemas de arquivos modernos suporta um sistema de diretório hierárquico, no qual os 
diretórios podem ter subdiretórios ad infinitum. 

Quando visto de dentro, um sistema de arquivos parece bem diferente. Os projetistas de 
sistema de arquivos precisam preocupar-se com o modo como o espaço de armazenamento 
é alocado e como o sistema monitora qual bloco fica em qual arquivo. Também vimos como 
diferentes sistemas têm diferentes estruturas de diretório. A confiabilidade e o desempenho 
do sistema de arquivos também são questões importantes. 

A segurança e a proteção são de interesse vital tanto para os usuários do sistema como 
para os projetistas. Discutimos algumas falhas de segurança nos sistemas mais antigos e pro- 
blemas genéricos que muitos sistemas têm. Também vimos a autenticação, com e sem senhas, 
as listas de controle de acesso e as capacitações, assim como um modelo de matriz para pen- 
sar sobre a proteção. 

Finalmente, estudamos o sistema de arquivos do MINIX 3 em detalhes. Ele é grande, 
mas não muito complicado. Ele aceita requisições de processos de usuário, indexa uma ta- 
bela de ponteiros de função e chama a função para executar a chamada de sistema solicitada. 
Devido a sua estrutura modular e a sua posição fora do núcleo, ele pode ser removido do 
MINIX 3 e usado como um servidor de arquivos de rede independente, com apenas pequenas 
modificações. 

Internamente, o MINIX 3 coloca os dados em buffer em uma cache de blocos e tenta fa- 
zer leitura antecipada ao acessar um arquivo sequencialmente. Se a cache for suficientemente 
grande, a maior parte do texto do programa já se encontrará na memória, durante operações 
que acessam repetidamente um conjunto de programas em particular, como no caso de uma 
compilação. 
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PROBLEMAS 


O NTFS usa Unicode para nomear arquivos. O Unicode suporta caracteres de 16 bits. Cite uma vanta- 
gem da atribuição de nomes de arquivo Unicode em relação à atribuição de nomes de arquivo ASCII. 


Alguns arquivos começam com um número mágico. Para que serve isso? 


A Figura 5-4 lista alguns atributos de arquivo. Nessa tabela não está listada a paridade. Esse seria 
um atributo de arquivo útil? Em caso positivo, como ele poderia ser usado? 


Apresente 5 nomes de caminho diferentes para o arquivo /etc/passwd. (Dica: pense a respeito das 
entradas de diretório “” e “.”.) 


Os sistemas que suportam arquivos sequenciais sempre têm uma operação para retroceder arqui- 
vos. Os sistemas que suportam arquivos de acesso aleatório precisam disso também? 


Alguns sistemas operacionais fornecem uma chamada de sistema rename para dar um novo nome 
a um arquivo. Existe alguma diferença entre usar essa chamada para mudar o nome de um arquivo 
e copiar o arquivo em um novo arquivo com o nome novo, seguido da exclusão do antigo? 


Considere a árvore de diretórios da Figura 5-7. Se /usr/jim/ é o diretório de trabalho, qual é o nome 
de caminho absoluto do arquivo cujo nome de caminho relativo é ../ast/x? 


Considere a seguinte proposta. Em vez de ter uma única raiz para o sistema de arquivos, fornecer a 
cada usuário uma raiz pessoal. Isso torna o sistema mais flexível? Por que, sim, ou por que, não? 


O sistema de arquivos do UNIX tem uma chamada chroot que muda a raiz para um diretório dado. 
Isso tem implicações sobre a segurança? Se tiver, quais são elas? 


O sistema UNIX tem uma chamada para ler uma entrada de diretório. Como os diretórios são ape- 
nas arquivos, por que é necessário ter uma chamada especial? Os usuários não podem apenas ler os 
próprios diretórios brutos? 


Um PC padrão pode conter apenas quatro sistemas operacionais simultaneamente. Existe uma 
maneira de aumentar esse limite? Quais consegiiências sua proposta teria? 


A alocação contígua de arquivos leva à fragmentação do disco, conforme mencionado no texto. Essa 
fragmentação é interna ou externa? Faça uma analogia com algo discutido no capítulo anterior. 


A Figura 5-10 mostra a estrutura do sistema de arquivos FAT original usado no MS-DOS. Inicial- 
mente, esse sistema de arquivos tinha apenas 4096 blocos, de modo que uma tabela com 4096 en- 
tradas (12 bits) era suficiente. Se esse esquema precisasse ser estendido diretamente para sistemas 
de arquivos com 2” blocos, qual seria o espaço ocupado pela FAT? 


Um sistema operacional suporta apenas um diretório, mas permite que o diretório tenha arbitra- 
riamente muitos arquivos, com nomes de arquivo arbitrariamente longos. Algo parecido com um 
sistema de arquivos hierárquico pode ser simulado? Como? 


O espaço livre em disco pode ser monitorado usando-se uma lista de regiões livres ou um mapa 
de bits. Os endereços de disco exigem D bits. Para um disco com B blocos, F dos quais são livres, 
declare a condição sob a qual a lista de regiões livres usa menos espaço do que o mapa de bits. Para 
D tendo o valor de 16 bits, expresse sua resposta como uma porcentagem do espaço em disco que 
deve estar livre. 


Foi sugerido que a primeira parte de cada arquivo UNIX deve ser mantida no mesmo bloco de 
disco que seu i-node. Qual seria a vantagem disso? 


O desempenho de um sistema de arquivos depende da taxa de acertos da cache (a fração dos blocos 
encontrados na cache). Se demora 1 ms para atender uma requisição que está na cache, mas 40 
ms se for necessário uma leitura do disco, forneça uma fórmula para o tempo médio exigido para 
atender uma requisição se a taxa de acertos é h. Represente essa função graficamente, para valores 
deh de 0 a 1,0. 
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Qual é a diferença entre um vínculo estrito e um vínculo simbólico? Cite uma vantagem de cada 
um deles. 


Cite três armadilhas a serem evitadas ao se fazer backup de um sistema de arquivos. 


Um disco tem 4000 cilindros, cada um com 8 trilhas de 512 blocos. Uma busca demora 1 ms por 
cilindro movido. Se não for feita nenhuma tentativa de colocar os blocos de um arquivo próximos 
uns aos outros, dois blocos que são logicamente consecutivos (isto é, vêm um após o outro no ar- 
quivo) exigirão uma busca média, que demora 5 ms. Entretanto, se o sistema operacional faz uma 
tentativa de agrupar blocos relacionados, a distância média entre blocos pode ser reduzida para 2 
cilindros e o tempo de busca pode ser reduzido para 100 microssegundos. Quanto tempo demora 
para ler um arquivo de 100 blocos nos dois casos, se a latência rotacional é de 10 ms e o tempo de 
transferência é de 20 microssegundos por bloco? 


A compactação periódica do espaço de armazenamento no disco teria algum valor concebível? 
Explique. 


Qual é a diferença entre um vírus e um verme? Como cada um deles se reproduz? 


Depois de se formar, você se candidata a diretor do centro de computação de uma grande univer- 
sidade que acabou de se desfazer de seu sistema operacional antigo e trocou para o UNIX. Você é 
contratado. Quinze minutos depois de começar a trabalhar, seu assistente entra em seu escritório e 
grita: “alguns alunos descobriram o algoritmo que usamos para criptografar senhas e divulgaram 
na Internet”. O que você deve fazer? 


Dois alunos de ciência da computação, Carolyn e Elinor, estão discutindo a respeito dos i-nodes. 
Carolyn sustenta que as memórias ficaram tão grandes e baratas que, quando um arquivo é aberto, 
é mais simples e rápido apenas buscar uma nova cópia do i-node na tabela de i-nodes, em vez de 
pesquisar a tabela inteira para ver se ele já está lá. Elinor discorda. Quem está com a razão? 


O esquema proteção de Morris-Thompson, com os números aleatórios de n bits, foi projetado para 
tornar difícil para um intruso descobrir um grande número de senhas cifrando strings comuns an- 
tecipadamente. O esquema também oferece proteção contra um aluno usuário que esteja tentando 
adivinhar a senha do superusuário em sua máquina? 


Um departamento de ciência da computação tem um grande número de máquinas UNIX em sua 
rede local. Os usuários em qualquer máquina podem executar um comando da forma 


machine4 who 


e executá-lo em machine4, sem que o usuário precise se conectar na máquina remota. Esse 
recurso é implementado fazendo-se com que o núcleo do usuário envie o comando e seu uid 
para a máquina remota. Esse esquema é seguro se todos os núcleos são confiáveis (por exem- 
plo, grandes minicomputadores de compartilhamento de tempo com hardware de proteção)? E 
se algumas das máquinas forem computadores pessoais de alunos, sem nenhum hardware de 
proteção? 


Quando um arquivo é removido, seus blocos geralmente são colocados de volta na lista de regiões 
livres, mas não são apagados. Você acha que seria uma boa idéia fazer o sistema operacional apagar 
cada bloco antes de liberá-lo? Considere os fatores de segurança e desempenho em sua resposta e 
explique o efeito de cada um. 


Três mecanismos de proteção diferentes que foram discutidos são as capacitações, as listas de con- 
trole de acesso e os bits rwx do UNIX. Para cada um dos problemas de proteção a seguir, indique 
qual desses mecanismos pode ser usado. 


(a) Ken quer que seus arquivos sejam lidos por todo mundo, exceto por seu colega de escritório. 
(b) Mitch e Steve querem compartilhar alguns arquivos secretos. 
(c) Linda quer que alguns de seus arquivos sejam públicos. 


Para o UNIX, suponha que os grupos são categorias como corpo docente, alunos, secretárias etc. 
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O ataque com cavalo de Tróia pode funcionar em um sistema protegido por capacitações? 


O tamanho da tabela filp é definido atualmente como uma constante, NR FILPS, em fs/const.h. Para 
acomodar mais usuários em um sistema interligado em rede, você quer aumentar NR PROCS em in- 
clude/minix/config.h. De que modo NR FILPS deve ser definida como uma função de NR PROCS? 


Suponha que ocorra um avanço tecnológico e que a memória RAM não-volátil, que mantém seu 
conteúdo confiável após uma falta de energia, torne-se disponível sem nenhuma desvantagem de 
preço ou desempenho em relação à memória RAM convencional. Quais aspectos do projeto do 
sistema de arquivos seriam afetados por esse desenvolvimento? 


Os vínculos simbólicos são arquivos que apontam indiretamente para outros arquivos ou diretó- 
rios. Ao contrário dos vínculos escritos, como aqueles atualmente implementados no MINIX 3, 
um vínculo simbólico tem seu próprio i-node, o qual aponta para um bloco de dados. O bloco de 
dados contém o caminho para o arquivo que está sendo vinculado e o i-node torna possível que 
o vínculo tenha diferentes posses e permissões em relação ao arquivo vinculado. Um vínculo 
simbólico e o arquivo ou diretório para o qual ele aponta podem estar localizados em dispositivos 
diferentes. Os vínculos simbólicos não fazem parte do MINIX 3. Implemente vínculos simbólicos 
para o MINIX 3. 


Embora o limite atual para o tamanho de um arquivo no MINIX 3 seja determinado pelo ponteiro 
de arquivo de 32 bits, no futuro, com ponteiros de arquivo de 64 bits, arquivos maiores do que 2”? 
— 1 bytes poderão ser permitidos, no caso em que blocos de tripla indireção poderão ser necessá- 
rios. Modifique o sistema de arquivos para adicionar blocos de tripla indireção. 


Verifique se o flag ROBUST (agora não utilizado) poderia tornar o sistema de arquivos mais ou 
menos robusto na presença de uma falha. Não foi pesquisado se esse é o caso na versão corrente 
do MINIX 3; portanto, uma das duas hipóteses pode ser verdadeira. Dê uma boa olhada no que 
acontece quando um bloco modificado é retirado da cache. Leve em conta que um bloco de dados 
modificado pode ser acompanhado de um i-node e de um mapa de bits modificados. 


Projete um mecanismo para adicionar suporte para um sistema de arquivos “estrangeiro”, de modo 
que se poderia, por exemplo, montar um sistema de arquivos MS-DOS em um diretório no sistema 
de arquivos MINIX 3. 


Escreva dois programas, em C ou como scripts shell, para enviar e receber uma mensagem por 
meio de um canal secreto em um sistema MINIX 3. Dica: um bit de permissão pode ser visto mes- 
mo quando um arquivo é inacessível de outras formas e é garantido que o comando ou chamada de 
sistema sleep atrasa por um período de tempo fixo, configurado por seu argumento. Meça a taxa de 
dados em um sistema ocioso. Em seguida, crie uma carga artificialmente pesada, iniciando muitos 
processos de segundo plano diferentes e meça a taxa de dados novamente. 


Implemente arquivos imediatos no MINIX 3, que sejam arquivos pequenos armazenados no pró- 
prio i-node, economizando assim um acesso ao disco para recuperá-los. 


6.1 


6.1.1 


LEITURAS RECOMENDADAS 
E BIBLIOGRAFIA 


Nos cinco capítulos anteriores, abordamos uma variedade de assuntos. Este capítulo se des- 
tina a ajudar os leitores que estejam interessados em levar adiante seu estudo sobre sistemas 
operacionais. A Seção 6.1 é uma lista de leituras sugeridas. A seção 6.2 é uma bibliografia em 
ordem alfabética de todos os livros e artigos citados neste livro. 

Além das referências dadas a seguir, os Proceedings of the n-th ACM Symposium on 
Operating Systems Principles (ACM) realizados bianualmente e os Proceedings of the n-th 
International Conference on Distributed Computing Systems (IEEE) realizados anualmente 
são bons lugares para procurar artigos recentes sobre sistemas operacionais. Assim como o 
Symposium on Operating Systems Design and Implementation da USENIX. Além disso, o 
ACM Transactions on Computer Systems e o Operating Systems Review são dois periódicos 
que frequentemente apresentam artigos relevantes. 


SUGESTÕES PARA LEITURAS COMPLEMENTARES 


A seguir está uma lista das leituras sugeridas dispostas por capítulo. 


Introdução e funcionamentos gerais 


Bovet e Cesati, Understanding the Linux Kernel, 3º Ed. Para qualquer um que queira enten- 
der como o núcleo do Linux funciona internamente, este livro provavelmente é sua melhor 
aposta. 


Brinch Hansen, Classic Operating Systems 

O sistema operacional já existe há tempo suficiente para que alguns deles possam ser consi- 
derados clássicos: sistemas que mudaram o modo de ver os computadores. Este livro é uma 
coleção de 24 artigos sobre sistemas operacionais embrionários, classificados como siste- 
mas operacionais abertos, de lote (batch), de multiprogramação, de tempo compartilhado, de 
computador pessoal e distribuídos. Quem estiver interessado na história dos sistemas opera- 
cionais deve ler este livro. 


Brooks, The Mythical Man-Month: Essays on Software Engineering 
Um livro informativo, divertido e engenhoso sobre como não escrever um sistema operacio- 
nal, feito por alguém que aprendeu da maneira mais difícil. Está repleto de bons conselhos. 
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Corbató, “On Building Systems That Will Fail” 

Em seu discurso no Turing Award, o pai do compartilhamento de tempo trata de muitas das 
mesmas preocupações abordadas por Brooks no livro Mythical Man-Month. Sua conclusão 
é a de que todos os sistemas complexos acabarão por apresentar problemas e que, para ter 
alguma chance de êxito, é absolutamente fundamental evitar a complexidade e lutar pela sim- 
plicidade e pela elegância no projeto. 


Deitel et al, Operating Systems, 3º Ed. 
Um livro-texto geral sobre sistemas operacionais. Além do material padrão, ele contém estu- 
dos de caso detalhados do Linux e do Windows XP. 


Dijkstra, “My Recollections of Operating System Design” 
Lembranças de um dos pioneiros do projeto de sistemas operacionais, começando no tempo 
em que o termo “sistema operacional” ainda não era conhecido. 


IEEE, Information Technology —Portable Operating System Interface (POSIX), Part 1: Sys- 
tem Application Program Interface (API) [C Language] 

Este é o padrão. Algumas partes são bastante fáceis de ler, especialmente o Anexo B, “Ratio- 
nale and Notes”, que esclarece por que as coisas são feitas como são. Uma vantagem de se 
referir ao documento padrão é que, por definição, não existem erros. Se um erro tipográfico 
em um nome de macro passa pelo processo de edição, ele não é mais um erro, é oficial. 


Lampson, “Hints for Computer System Design” 

Butler Lampson, um dos maiores projetistas do mundo de sistemas operacionais inovadores, 
colecionou muitas dicas, sugestões e diretrizes de seus vários anos de experiência e os reuniu 
neste artigo interessante e informativo. Assim como o livro de Brook, esta é uma leitura obri- 
gatória para todo projetista de sistema operacional iniciante. 


Lewine, POSIX Programmer's Guide 

Este livro descreve o padrão POSIX de uma maneira muito mais fácil de ler do que o docu- 
mento de padrões em si e inclui discussões sobre como converter programas antigos para o 
POSIX e como desenvolver novos programas para o ambiente POSIX. Existem muitos exem- 
plos de código, incluindo vários programas completos. Estão descritas todas as funções de 
biblioteca e os arquivos de cabeçalho exigidos pelo POSIX. 


McKusick e Neville-Neil, The Design and Implementation of the FreeBSD Operating System 
Para uma explicação completa do funcionamento interno de uma versão moderna do UNIX, 
neste caso, o FreeBSD, este é o lugar certo para consultar. Ele aborda processos, E/S, geren- 
ciamento de memória, interligação em rede e praticamente tudo mais. 


Milojicic, “Operating Systems: Now and in the Future” 

Suponha que você fosse fazer uma série de perguntas sobre sistemas operacionais e para 
onde eles estão indo, para seis dos maiores especialistas do mundo. Você obteria as mesmas 
respostas? Dica: Não. Descubra aqui o que eles disseram. 


Ray e Ray, Visual Quickstart Guide: UNIX, 2º Ed. 

Se você se sente à vontade como usuário de UNIX, isso o ajudará a entender os exemplos 
deste livro. Este é apenas um dos vários guias para o iniciante, para trabalhar com o sistema 
operacional UNIX. Embora seja implementado de forma diferente, para o usuário, o MINIX 


é parecido com o UNIX e este livro ou um livro semelhante também será útil em seu trabalho 
com o MINIX. 
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Russinovich e Solomon, Microsoft Windows Internals, 4º Ed. 

Você já se perguntou como o Windows funciona por dentro? Não se pergunte mais. Este livro 
diz tudo que você provavelmente gostaria de saber sobre processos, gerenciamento de memó- 
ria, E/S, interligação em rede, segurança e muito mais. 


Silberschatz et al, Operating System Concepts, 1° Ed. 

Outro livro-texto sobre sistemas operacionais. Ele aborda processos, gerenciamento do es- 
paço de armazenamento, arquivos e sistemas distribuídos. São dados dois estudos de caso: 
Linux e Windows XP. 


Stallings, Operating Systems, 5º Ed. 

Um outro livro-texto sobre sistemas operacionais. Ele aborda todos os assuntos normais e 
também inclui um pequeno volume de material sobre sistemas distribuídos, além de um apên- 
dice sobre teoria de filas. 


Stevens e Rago, Advanced Programming in the UNIX Environment, 2º Ed. 

Este livro fala sobre como escrever programas em C que usam a interface de chamada de 
sistema do UNIX e a biblioteca C padrão. Os exemplos foram testados no FreeBSD 5.2.1, no 
kernel do Linux 2.4.22, no Solaris 9, no Darwin 7.4.0 e na base FreeBSD/Mach do Mac OS X 
10.3. O relacionamento dessas implementações com o POSIX está descrita em detalhes. 


Processos 


Andrews e Schneider, “Concepts e Notations for Concurrent Programming” 

Um exercício dirigido e um levantamento dos processos e da comunicação entre processos, 
incluindo espera ativa, semáforos, monitores, passagem de mensagens e outras técnicas. O 
artigo também mostra como esses conceitos são incorporados em várias linguagens de pro- 
gramação. 


Ben-Ari, Principles of Concurrent and Distributed Programming 

Este livro consiste em três partes; a primeira tem capítulos sobre exclusão mútua, semáforos, 
monitores e o problema da janta dos filósofos, entre outros. A segunda parte discute a progra- 
mação distribuída e as linguagens úteis para a programação distribuída. A terceira parte fala 
sobre os princípios de implementação da concorrência. 


Bic e Shaw, Operating System Principles 
Este livro-texto sobre sistemas operacionais tem quatro capítulos sobre processos, incluindo 
não apenas os princípios normais, mas também bastante material sobre implementação. 


Milo et al., “Process Migration” 

À medida que agrupamentos de PCs (clusters) substituem gradualmente os supercomputado- 
res, a questão de migrar processos de uma máquina para outra (por exemplo, para balancear a 
carga) está se tornando mais relevante. Neste levantamento, os autores discutem o funciona- 
mento da migração de processos, junto com suas vantagens e armadilhas. 


Silberschatz et al, Operating System Concepts, 1° Ed. 

Os capítulos 3 a 7 abordam processos e comunicação entre processos, incluindo escalona- 
mento, seções críticas, semáforos, monitores e problemas clássicos da comunicação entre 
processos. 
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6.1.4 


Entrada/saída 


Chen et al., “RAID: High Performance Reliable Secondary Storage” 

O uso de várias unidades de disco em paralelo para obter uma E/S rápida é uma tendência nos 
sistemas de ponta. Os autores discutem essa idéia e examinam diferentes organizações, em 
termos de desempenho, custo e confiabilidade. 


Coffman et al., “System Deadlocks” 
Uma breve introdução para os impasses, o que os causam e como eles podem ser evitados ou 
detectados. 


Corbet et al., Linux Device Drivers, 3º Ed. 
Se você quer saber muito, mas muito, muito mesmo, de como a E/S funciona, tente escrever 
um driver de dispositivo. Este livro diz como você faz isso para o Linux. 


Geist e Daniel, “A Continuum of Disk Scheduling Algorithms” 
E apresentado um algoritmo generalizado para escalonamento de disco. São fornecidos mui- 
tos resultados de simulação e experimentais. 


Holt, “Some Deadlock Properties of Computer Systems” 
Uma discussão sobre impasses. Holt apresenta um modelo de grafo dirigido que pode ser 
usado para analisar algumas situações de impasse. 


IEEE Computer Magazine, Março de 1994 

Este volume da Computer contém oito artigos sobre E/S avançada e aborda simulação, ar- 
mazenamento de alto desempenho, uso de cache, E/S para computadores paralelos e multi- 
mídia. 


Levine, “Defining Deadlocks” 
Neste artigo curto, Levine levanta interessantes questões sobre definições convencionais e 
exemplos de impasse. 


Swift et al., “Recovering Device Drivers” 

Os drivers de dispositivo têm uma taxa de erros bem mais alta do que qualquer outro código 
do sistema operacional. Há algo que possa ser feito para melhorar a confiabilidade? Este arti- 
go descreve como se pode atingir esse objetivo. 


Tsegaye e Foss, “A Comparison of the Linux and Windows Device Driver Architecture” 
O Linux e o Windows têm arquiteturas muito diferentes para seus drivers de dispositivo. Este 
artigo discute as duas e mostra em que elas são semelhantes e como são diferentes. 


Wilkes et al., “The HP AutoRAID Hierarchical Storage System” 

Um importante novo desenvolvimento nos sistemas de disco de alto desempenho é o RAID 
(Redundant Array of Inexpensive Disks), no qual um grupo de discos trabalha em conjunto 
para produzir um sistema com alta largura de banda. Neste artigo, os autores descrevem com 
alguns detalhes o sistema que construíram nos laboratórios da HP. 


Gerenciamento de memória 


Bic e Shaw, Operating System Principles 
Três capítulos deste livro são dedicados ao gerenciamento de memória, à memória física, à 
memória virtual e à memória compartilhada. 
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Denning, “Virtual Memory” 
Um artigo clássico sobre muitos aspectos da memória virtual. Denning foi um dos pioneiros 
nesse setor e foi o inventor do conceito de conjunto de trabalho. 


Denning, “Working Sets Past and Present” 
Um bom panorama dos numerosos algoritmos de gerenciamento de memória e paginação. E 
incluída uma ampla bibliografia. 


Denning, “The Locality Principle” 
Uma retrospectiva recente da história do princípio da localidade e uma discussão sobre sua 
aplicabilidade em diversos problemas, além das questões sobre paginação da memória. 


Halpern, “VIM: Taming Software with Hardware” 

Neste artigo provocante, Halpern argumenta que um tremendo volume de dinheiro está sen- 
do gasto para produzir, depurar e manter software que trata com otimização da memória e 
não apenas em sistemas operacionais, mas também em compiladores e outro software. Ele 
argumenta que, em uma visão macro-econômica, seria melhor gastar esse dinheiro apenas 
comprando mais memória e tendo software simples e mais confiável. 


Knuth, The Art of Computer Programming, Vol. 1 
Os algoritmos do primeiro que couber, do que melhor couber e outros algoritmos de gerencia- 
mento de memória são discutidos e comparados neste livro. 


Silberschatz et al, Operating System Concepts, 1° Ed. 
Os capítulos 8 e 9 tratam do gerenciamento de memória, incluindo swapping, paginação e 
segmentação. Vários algoritmos de paginação são mencionados. 


Sistemas de arquivos 


Denning, “The United States vs. Craig Neidorf” 

Quando um jovem hacker descobriu e publicou informações sobre o funcionamento do sis- 
tema telefônico, ele foi indiciado por fraude de computador. Este artigo descreve o caso, que 
envolveu muitas questões fundamentais, incluindo a liberdade de expressão. O artigo é acom- 
panhado por alguns pareceres discordantes e uma refutação de Denning. 


Ghemawat et al., “The Google File System” 

Suponha que você tenha decidido que deseja armazenar a Internet inteira em casa, para que 
possa encontrar as coisas de forma realmente rápida. Como você faria isso? O passo 1 seria 
comprar, digamos, 200.000 PCs. PCs comuns serviriam. Nada fantástico é necessário. O pas- 
so 2 seria ler este artigo para descobrir como o Google faz isso. 


Hafner e Markoff, Cyberpunk: Outlaws and Hackers on the Computer Frontier 

Três fascinantes contos sobre jovens hackers invadindo computadores pelo mundo são con- 
tadas aqui pelo repórter de informática do New York Times responsável pelo furo de reporta- 
gem sobre o verme que assolou a Internet, e seu co-autor. 


Harbron, File Systems: Structures and Algorithms 
Um livro sobre projeto de sistemas de arquivos, aplicações e desempenho. São abordados a 
estrutura e os algoritmos. 
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Harris et al., Gray Hat Hacking: The Ethical Hacker's Handbook 

Este livro discute os aspectos jurídicos e éticos dos testes de vulnerabilidades nos sistemas de 
computador, assim como fornece informações técnicas sobre como elas são geradas e como 
podem ser detectadas. 


McKusick et al., “A Fast File System for UNIX” 
O sistema de arquivos do UNIX foi completamente reimplementado para o 4.2 BSD. Este 
artigo descreve o projeto do novo sistema de arquivos e discute seu desempenho. 


Satyanarayanan, “The Evolution of Coda” 

À medida que a computação móvel se torna mais comum, a necessidade de integrar e sincro- 
nizar sistemas de arquivos móveis e fixos se torna mais urgente. O Coda foi pioneiro nessa 
área. Sua evolução e operação são descritos neste artigo. 


Silberschatz et al Operating System Concepts, 7º Ed. 

Os capítulos 10 e 11 falam sobre sistemas de arquivos. Eles abordam as operações de arquivo, 
os métodos de acesso, a semântica da consistência, diretórios, proteção e implementação, 
dentre outros assuntos. 


Stallings, Operating Systems, 5º Ed. 
O capítulo 16 contém muito material sobre o ambiente de segurança, especialmente sobre 
hackers, vírus e outras ameaças. 


Uppuluri et al., “Preventing Race Condition Attacks on File Systems” 

Existem situações em que um processo presume que duas operações serão executadas de 
forma atômica, sem nenhuma operação intermediária. Se outro processo consegue entrar sor- 
rateiramente e executar uma operação entre elas, a segurança pode ser comprometida. Este 
artigo discute o problema e propõe uma solução. 


Yang et al., “Using Model Checking to Find Serious File System Errors” 

Os erros do sistema de arquivos podem levar à perda de dados; portanto, depurá-los é muito 
importante. Este artigo descreve uma técnica formal que ajuda a detectar erros do sistema de 
arquivos antes que eles possam causar danos. É apresentado o resultado do uso do verificador 
de modelo no código do sistema de arquivos real. 
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APÊNDICE A 


INSTALANDO O MINIX 3 


A.1 


A 


INSTALANDO O MINIX 3 


Este apêndice explica como instalar o MINIX 3. Uma instalação completa do MINIX 3 exige 
um processador Pentium (ou compatível) com pelo menos 16 MB de memória RAM, 1 GB 
de espaço livre em disco, um CD-ROM IDE e um disco rígido IDE. Uma instalação mínima 
(sem os fontes) exige 8 MB de memória RAM e 50 MB de espaço em disco. Atualmente não 
são suportados discos do tipo ATA, interfaces USB e SCSI seriais. Para CD-ROMS USB, 
consulte o site da Web: www.minix3.org. 


PREPARAÇÃO 


Se você já tem o CD-ROM (por exemplo, do livro), então pode pular os passos 1 e 2, mas é 
aconselhável consultar o endereço www.minix3.org para ver se existe uma versão mais recen- 
te disponível. Se você quiser executar o MINIX 3 em um simulador, em vez de usar a forma 
nativa, consulte primeiro a Parte V. Se você não tem um CD-ROM IDE, obtenha a imagem de 
inicialização especial do CD-ROM USB ou use um simulador. 


Download da imagem de CD-ROM do MINIX 3 
Faça o download da imagem de CD-ROM do MINIX 3 a partir do site web do MINIX 3 no 
endereço www.minix3.org. 


Crie um CD-ROM de inicialização do MINIX 3 

Descompacte o arquivo obtido por download. Você obterá um arquivo de imagem de CD- 
ROM com a extensão .iso e este manual. O arquivo .iso é uma imagem de CD-ROM, bit por 
bit. Grave-o em um CD-ROM para ter um CD-ROM de inicialização. 

Se você estiver usando Easy CD Creator 5, selecione “Record CD from CD image” no 
menu Arquivo e mude o tipo de arquivo de .cif para .iso, na caixa de diálogo que aparece. Se- 
lecione o arquivo de imagem e clique em “Open”. Em seguida, clique em “Start Recording”. 

Se você estiver usando Nero Express 5, escolha “Disc Image or Saved Project” e mude 
o tipo para “Image Files”, selecione o arquivo de imagem e clique em “Open”. Selecione seu 
gravador de CD e clique em “Next”. 

Se você estiver executando o Windows XP e não tem um programa de gravação de CD- 
ROM, dê uma olhada no endereço alexfeinman.brinkster.net/isorecorder.htm para obter um 
gratuitamente e utilize-o para criar uma imagem do CD. 
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3. 


A.2 


Determine a controladora Ethernet que você tem 

O MINIX 3 suporta vários controladores Ethernet para conexãoão em rede local, ADSL e 
a cabo. Isso inclui os chips Intel Pro/100, RealTek 8029 e 8139, AMD LANCE e vários da 
3Com. Durante a configuração, será perguntado qual controladora Ethernet você tem. Deter- 
mine isso examinando a documentação de seu computador. Como alternativa, se você estiver 
usando Windows, vá até o gerenciador de dispositivos, como segue: 


Windows 2000: Iniciar > Configurações > Painel de Controle > Sistema > Hardware > 
Gerenciador de Dispositivos 

Windows XP: Iniciar > Painel de Controle > Sistema > Hardware > Gerenciador de 
Dispositivos 


A opção Sistema exige um duplo clique; o resto exige um clique simples. Expanda o sinal de 
+ ao lado de “Adaptadores de rede” para ver quais você tem em sua máquina. Tome nota. Se 
você não tem uma controladora suportada, mesmo assim você ainda pode executar o MINIX 
3, mas sem Ethernet. 


Particione seu disco rígido 

Se desejar, você pode inicializar o computador com o MINIX 3 a partir de CD-ROM, mas 
para fazer algo útil, é preciso criar uma partição para ele em seu disco rígido. Mas, antes de 
particionar, certifique-se de fazer backup de seus dados em uma mídia externa, como um 
CD-ROM ou DVD, como precaução de segurança, apenas para o caso de algo dar errado. 
Seus arquivos são valiosos; proteja-os. 

A não ser que você tenha certeza de que é especialista em particionamento de disco, 
com muita experiência, recomenda-se veementemente que leia o exercício dirigido on-line 
sobre particionamento de disco, no endereço www.minix3.org/doc/partitions.html. Se você já 
sabe gerenciar partições, crie uma área livre em disco de pelo menos 50 MB ou, se quiser to- 
das as fontes, crie uma área de 1 GB. Se você não sabe gerenciar partições, mas tem um pro- 
grama de particionamento como o Partition Magic, utilize-o para criar uma região de espaço 
livre no disco. Além disso, certifique-se de que haja pelo menos uma partição principal (isto 
é, a entrada Master Boot Record) livre. O script de configuração do MINIX 3 o conduzirá na 
criação de uma partição MINIX no espaço livre, que pode estar no primeiro ou no segundo 
disco IDE. 

Se você estiver executando o Windows 95, 98, ME ou 2000 e seu disco consiste em 
uma única partição FAT, então pode usar o programa presz134.exe no CD-ROM (também 
disponível no endereço zeleps.com) para reduzir seu tamanho, a fim de deixar espaço para o 
MINIX. Em todos os outros casos, leia cuidadosamente o exercício dirigido on-line citado 
anteriormente. 

Se seu disco é maior do que 128 GB, a partição do MINIX 3 deverá ficar inteiramente 
nos primeiros 128 GB (devido à maneira como os blocos de disco são endereçados). 

Alerta: se você cometer um erro durante o particionamento de disco, poderá per- 
der todos os dados do disco; portanto, antes de começar, faça o backup deles em um 
CD-ROM ou em um DVD. O particionamento de disco exige muito cuidado; portanto, 
proceda com cautela. 


INICIALIZAÇÃO 


Agora você já deve ter alocado algum espaço livre em seu disco. Se você ainda não fez isso, 
faça agora, a menos que já exista uma partição que queira converter para o MINIX 3. 
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Inicialização a partir do CD-ROM 

Insira o CD-ROM em sua respectiva unidade e inicialize o computador a partir dele. Se você 
tiver 16 MB de memória RAM ou mais, escolha “regular”; se tiver apenas 8 MB, escolha 
“small”. Se o computador inicializar a partir do disco rígido, em vez do CDROM, repita o 
procedimento e entre no programa de configuração da BIOS para mudar a ordem dos dispo- 
sitivos de inicialização, colocando o CD-ROM antes do disco rígido. 


Login como root 


Quando o prompt do login aparecer, conecte-se como root. Após um login bem-sucedido 
como root, você verá o prompt do shell (&). Nesse ponto, você está executando o MINIX 3 de 
forma totalmente operacional. Se você digitar: 


Is /usr/bin | more 


poderá ver que software está disponível. Pressione a barra de espaço para rolar a lista. Para 
verificar o que o programa foo faz, digite: 


man foo 


As páginas de manual também estão disponíveis no endereço www.minix3.org/manpages. 


Inicie o script de configuração 
Para iniciar a instalação do MINIX 3 no disco rígido, digite 


setup 


Depois desse e de todos os outros comandos, certifique-se de digitar ENTER (RETURN). Quan- 
do o script de instalação termina, aparece uma tela com dois-pontos; pressione ENTER para con- 
tinuar. Se a tela ficar em branco repentinamente, pressione CTRL-F3 para selecionar a rolagem 
por software (isso só deve ser necessário em computadores muito antigos). Note que CTRL.-tecla 
significa pressionar a tecla CTRL e, enquanto a mantém pressionada, pressionar “tecla”. 


INSTALANDO NO DISCO RÍGIDO 


Estes passos correspondem aos que aparecem na tela. 


Selecione o tipo de teclado 
Quando solicitado, selecione o seu tipo de teclado. Este e outros passos têm uma escolha 
padrão, entre colchetes. Se você concordar com ela, basta pressionar ENTER. Na maioria dos 


passos, o padrão geralmente é uma boa escolha para os iniciantes. O teclado us-swap permuta 
as teclas CAPS LOCK e CTRL, como é convenção nos sistemas UNIX. 


Selecione seu controlador Ethernet 


Agora, será perguntado quais dos drivers Ethernet disponíveis você deseja instalar (ou ne- 
nhum). Escolha uma das opções. 


Distribuição mínima básica ou completa? 

Se você tiver pouco espaço em disco, selecione M, para uma instalação mínima, que inclui 
todos os binários, mas apenas os códigos-fonte do sistema. A opção mínima não instala os 
códigos-fonte dos comandos. 50 MB são suficientes para um sistema básico. Se você tiver 1 
GB ou mais, escolha F, para uma instalação completa. 
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4. Crie ou selecione uma partição para o MINIX 3 


Primeiro, será perguntado se você é especialista em particionamento de disco MINIX 3. Se 
for, você será levado ao programa part para receber o poder de editar o Master Boot Record (e 
corda suficiente para se enforcar). Se você não é especialista, pressione ENTER para a ação 
padrão, que é um guia passo a passo automatizado para formatar uma partição de disco para 
o MINIX 3. 


Sub-passo 4.1: Selecione um disco para instalar o MINIX 3 


Uma controladora IDE pode ter até quatro discos. O script de configuração procurará cada 
um deles. Ignore as mensagens de erro. Quando as unidades de disco forem listadas, selecio- 
ne uma e confirme sua escolha. Se você tem dois discos rígidos e decidir instalar o MINIX 3 
no segundo e tiver problemas para inicializar a partir dele, consulte o endereço www. minix3. 
org/doc/using2disks.html para ver a solução. 


Sub-passo 4.2: Selecione uma zona do disco 


Agora, escolha uma zona para instalar o MINIX 3. Você tem três escolhas: 


(1) Selecionar uma zona livre 
(2) Selecionar uma partição para sobrescrever 


(3) Excluir uma partição para liberar espaço e combiná-la com o espaço livre adjacente 


Para as escolhas (1) e (2), digite o número da zona. Para a (3), digite 
delete 


e, então, forneça o número da zona, quando solicitado. Essa zona será sobrescrita e seu con- 
teúdo anterior será perdido para sempre. 


Sub-passo 4.3: Confirme suas escolhas 


Agora, você chegou ao ponto sem volta. Será perguntado se você deseja continuar. Se você 
aceitar, os dados na zona selecionada serão removidos para sempre. Se você tiver certeza, 
digite: 


yes 


e, em seguida, ENTER. Para sair do script de configuração sem mudar a tabela de partição, 
pressione CTRL-C. 


Escolha de reinstalação 

Se você escolheu uma partição existente do MINIX 3, neste passo será oferecida uma escolha 
entre uma instalação completa, que apagará tudo que há na partição, e uma reinstalação, que 
não afetará sua partição /home existente. Esse projeto significa que você pode colocar seus 
arquivos pessoais em /home e reinstalar uma versão mais recente do MINIX 3, quando estiver 
disponível, sem perder seus arquivos pessoais. 


Selecione o tamanho de /home 

A partição selecionada será dividida em três subpartições: root, /usr e /home. Esta última é 
para seus próprios arquivos. Especifique quanto da partição deve ser separado para seus ar- 
quivos. Será solicitado para que você confirme sua escolha. 
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Selecione um tamanho de bloco 


São suportados tamanhos de bloco de disco de 1 KB, 2 KB, 4 KB e 8 KB, mas para usar um 
tamanho maior do que 4 KB, você precisa alterar uma constante e recompilar o sistema. Se 
sua memória tem 16 MB ou mais, use o padrão (4 KB); caso contrário, use 1 KB. 


Espere pela detecção de blocos defeituosos 


Agora, o script de configuração percorrerá cada partição para localizar blocos de disco de- 
feituosos. Isso levará vários minutos, possivelmente 10 minutos ou mais em uma partição 
grande. Seja paciente. Se você tiver absoluta certeza de que não existem blocos defeituosos, 
pode eliminar cada varredura pressionando CTRL-C. 


Espere que os arquivos sejam copiados 

Quando a varredura terminar, os arquivos serão copiados automaticamente do CD-ROM para 
o disco rígido. Cada arquivo copiado é mostrado na tela. Quando a cópia terminar, o MINIX 
3 estará instalado. Desligue o sistema, digitando 


shutdown 


Para evitar perda de dados, sempre pare o MINIX 3 dessa maneira, pois o MINIX 3 man- 
tém alguns arquivos no disco de RAM e só os copia no disco rígido no momento da parada 
(shutdown). 


TESTANDO SUA INSTALAÇÃO 


Esta seção diz como testar sua instalação, reconstruir o sistema após modificá-lo e inicializá- 
lo posteriormente. Para começar, inicialize seu novo sistema MINIX 3. Por exemplo, se você 
usou a controladora 0, disco 0, partição 3, digite 


boot cOdOp3 


e conecte-se como root. Sob condições muito raras, o número da unidade de disco vista pela 
BIOS (e utilizada pelo monitor de inicialização) pode não concordar com aquele usado pelo 
MINIX 3. Tente primeiro o que foi anunciado pelo script de configuração. Esse é um bom 
momento para criar uma senha de root. Para obter ajuda, consulte man passwd. 


Compile a sequência de testes 
Para testar o MINIX 3, no prompt de comando (*), digite 


cd /usr/srcitest 
make 


e espere até que ele termine todas as 40 compilações. Desconecte-se digitando CTRL-D, 


Execute a seqüência de teste 
Para testar o sistema, conecte-se como bin (exigido) e digite 


cd /usr/srcitest 
“run 


para executar os programas de teste. Todos eles devem funcionar corretamente, mas podem 
demorar 20 min em uma máquina rápida e mais de uma hora em uma máquina lenta. Nota: é 
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necessário compilar o conjunto de teste como root, mas execute-o como bin para ver se o bit 
setuid funciona corretamente. 


Reconstrua o sistema operacional inteiro 

Se todos os testes funcionaram corretamente, você pode agora reconstruir o sistema. Isso não 
é necessário, pois ele vem previamente construído, mas se você pretende modificar o sistema, 
precisará saber como fazer isso. Além disso, reconstruir o sistema é um bom teste para ver se 
ele funciona. Digite: 


cd /usr/src/tools 
make 


para ver as diversas opções disponíveis. Agora, faça uma nova imagem de inicialização, di- 
gitando 


su 
make clean 
time make image 


Você acabou de reconstruir o sistema operacional, incluindo todas as partes do núcleo e do 
modo usuário. Isso não demorou muito, demorou? Se você tiver uma unidade de disquete, é 
possível fazer um disquete de inicialização para usar posteriormente, inserindo um disquete 
formatado e digitando 


make fdboot 
Quando for solicitado a completar o caminho, digite: 


fdo 


Essa estratégia atualmente não funciona com disquetes USB, pois ainda não há nenhum su- 
porte a drivers de disquete USB no MINIX 3. Para atualizar a imagem de inicialização cor- 
rentemente instalada no disco rígido, digite 


make hdboot 


Desligue e reinicialize o novo sistema 
Para inicializar o novo sistema, primeiro desligue, digitando: 


shutdown 


Esse comando salva certos arquivos e leva de volta ao monitor de inicialização do MINIX 3. 
Para obter um resumo do que o monitor de inicialização pode fazer, enquanto se está nele, 
digite: 


help 


Para mais detalhes, consulte o endereço www.minix3.org/manpages/man8/boot.8.html. Ago- 
ra, você pode remover o CD-ROM, ou o disquete, e desligar o computador. 


Reinicializando o sistema 
Se você tem uma unidade de disquete, o modo mais simples de inicializar o MINIX 3 é in- 
serindo seu novo disquete de inicialização e ligando a energia. Isso demora apenas alguns 
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segundos. Como alternativa, inicialize a partir do CD-ROM do MINIX 3, conecte-se como 
bin e digite: 


shutdown 
para voltar ao monitor de inicialização do MINIX 3. Agora, digite: 
boot c0dOpO 


para inicializar a partir do arquivo de imagem do sistema operacional na controladora 0, dri- 
ver 0, partição 0. Naturalmente, se você tiver posto o MINIX 3 no driver O partição 1, use: 


boot cOdOp1 


e assim sucessivamente. 

Uma terceira possibilidade é tornar ativa a partição do MINIX 3 e usar o monitor de 
inicialização para disparar o MINIX 3 ou qualquer outro sistema operacional. Para ver os 
detalhes, consulte o endereço wyw.minix3.org/manpages/man8/boot.8.html. 

Finalmente, uma quarta opção é instalar um carregador de inicialização múltipla, como 
o LILO ou o GRUB (www. gnu.org/software/grub). Então, você poderá inicializar qualquer 
um de seus sistemas operacionais facilmente. Uma discussão sobre os carregadores de inicia- 
lização múltipla está fora dos objetivos deste guia, mas existem algumas informações sobre o 
assunto no endereço www.minix3.org/doc. 


USANDO UM SIMULADOR 


Uma estratégia completamente diferente para executar o MINIX 3 é executá-lo sobre outro 
sistema operacional, em vez da forma nativa simples. Várias máquinas virtuais, simuladores e 
emuladores estão disponíveis para esse propósito. Alguns dos mais populares são: 


e VMware (www.vmware.com) 
e Bochs (www.bochs.org) 
e QEMU (www.gemu.org) 


Consulte a documentação de cada um deles. Executar um programa em um simulador é se- 
melhante a executá-lo na máquina real; portanto, você deve voltar para a Parte I, obter o CD- 
ROM mais recente e continuar a partir desse ponto. 
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HEHEHEHEH HHHH HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH H+ HHH HHHH H+H HH H+H H+ HH+H+H+H+H+H+ 


include/ansi.h 


HEHEHEHEH HHHH HHHH H+H HH HH HH HH HHH HH HHH HH HHHH ++ 


00000 
00001 
00002 
00003 
00004 
00005 
00006 
00007 
00008 
00009 
00010 
00011 
00012 
00013 
00014 
00015 
00016 
00017 
00018 
00019 
00020 
00021 
00022 
00023 
00024 
00025 
00026 
00027 
00028 
00029 
00030 
00031 
00032 
00033 
00034 
00035 
00036 
00037 
00038 
00039 
00040 
00041 
00042 
00043 
00044 
00045 
00046 
00047 
00048 
00049 
00050 
00051 
00052 
00053 
00054 


/* O cabeçalho <ansi.h> tenta decidir se o compilador é suficientemente 
* compatível com o Standard C para que o Minix tire proveito dele. Se for, o 
* símbolo _ANSI será definido (como 31459). Caso contrário, 
mas poderá ser definido pelos aplicativos que queiram se submeter às regras. 


* às regras. 
* cabeçalhos, 


aqui, 
O número mágico na definição serve para inibir a submissão desnecessária 
(Por consistência com os novos testes de '#ifdef _ANSI" nos 
_ANSI deveria ser definido como nada, mas isso 

danificaria muitas rotinas de biblioteca que utilizam"#if _ANSI".) 


* Se _ANSI acabar sendo definido, uma macro 


* será definida. Essa macro se expande de diferentes maneiras, 


_PROTOTYPE (function, params) 


_ANSI não será definido 


gerando 


* prototypes Standard C ANSI ou prototypes de estilo antigo K&R (Kernighan & Ritchie), 


* As macros apropriadas estão definidas aqui. 


conforme for necessário. Finalmente, alguns programas usam _CONST, _VOIDSTAR etc 
de maneira tal que eles são portáveis nos compiladores ANSI e K&R. 


*/ 
tifndef  ANSI H 
tdefine ANSI H 
Hif — STDC == 
tdefine _ANSI 31459 /* o compilador exige tconformidade completa com ANSI */ 
#endif 
#ifdef _ GNUC | 
#define _ANSI 31459 /* gcc adapta-se o suficiente, até mesmo no modo não-ANSI*/ 
#endif 


#ifdef _ANSI 


/* Mantém tudo para prototypes ANSI. */ 


#define 
#define 


#define 
#define 
#define 
#define 
#define 


#else 


_PROTOTYPE (function, params) function params 
_ARGS (params) params 
_VOIDSTAR void * 

_VOID void 

- CONST const 

- VOLATILE volatile 

- SIZET size t 


/* Se desfaz dos parâmetros dos prototypes K&R . */ 


tdefine 
tdefine 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


- PROTOTYPECfunction, params) function) 


_ARGS (params) O 
_VOIDSTAR void * 

_VOID void 

- CONST 

- VOLATILE 

-SIZET int 
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00055 
00056 
00057 
00058 
00059 
00060 
00061 
00062 
00063 
00064 
00065 
00066 
00067 
00068 


#endif /* _ANSI */ 


/* Isto deve ser definido como restrito quando for usado o compilador C99. */ 
tdefine _RESTRICT 


/* Configurar _MINIX, | POSIX C SOURCE ou | POSIX2 SOURCE implica em 

*  POSIX SOURCE. (Parece errado colocar isso aqui, no espaço ANSI.) 
Hif definedC MINIX) || | POSIX C SOURCE > O || defined( POSIX2 SOURCE) 
gundef - POSIX SOURCE 
#define - POSIX SOURCE 1 
Hendif 


gendif /* ANSI H */ 


HHHHHHHHH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH H+H HHH H+H HHHH HHHH H+ HHH H+H+HH+H+H+H+H+H+ 


include/limits.h 


HEHEHEHEH HHHH HHHH HHHH H+H HH HH HHH HH HHHH H+H HH ++ 


00100 
00101 
00102 
00103 
00104 
00105 
00106 
00107 
00108 
00109 
00110 
00111 
00112 
00113 
00114 
00115 
00116 
00117 
00118 
00119 
00120 
00121 
00122 
00123 
00124 
00125 
00126 
00127 
00128 
00129 
00130 
00131 
00132 
00133 
00134 
00135 
00136 
00137 
00138 
00139 


/* O cabeçalho <limits.h> define alguns tamanhos básicos, tanto dos tipos de linguagem 
* (por exemplo, o número de bits em um valor inteiro) como do sistema operacional (por 
* exemplo, o número de caracteres em um nome de arquivo. 


E 


tifndef LIMITS H 
tdefine LIMITS H 


/* Definições sobre valores char (8 bits no MINIX e com sinal). */ 


#define CHAR BIT 8 /* número de bits em um char */ 

gdefine CHAR MIN 128 /* valor mínimo de um char */ 

define CHAR MAX 127 /* valor máximo de um char */ 

tdefine SCHAR MIN -128 /* valor mínimo de um char com sinal */ 

#define SCHAR MAX 127 /* valor máximo de um char com sinal */ 

#define UCHAR MAX 255 /* valor máximo de um char sem sinal */ 

tdefine MB LEN MAX 1 /* comprimento máximo de um caractere de vários bytes */ 


/* Definições sobre valores short (16 bits no MINIX). */ 

tdefine SHRT MIN (-32767-1) /* valor mínimo de um short */ 

tdefine SHRT MAX 32767 /* valor máximo de um short */ 

tdefine USHRT MAX OxFFFF /* valor máximo de um short sem sinal */ 


/* EM WSIZE é um símbolo gerado pelo compilador fornecendo o tamanho da palavra em bytes. */ 
ádefine INT MIN (-2147483647-1) /* valor mínimo de um int de 32 bits */ 

tdefine INT MAX 2147483647 /* valor máximo de um int de 32 bits */ 

tdefine UINT MAX OxFFFFFFFF /* valor máximo de um int de 32 bits sem sinal */ 


/*Definições sobre valores long (32 bits no MINIX). */ 

tdefine LONG MIN (-2147483647L-1) /* valor mínimo de um Tong */ 

#define LONG MAX 2147483647L  /* valor máximo de um long */ 

gdefine ULONG MAX OxFFFFFFFFL /* valor máximo de um long sem sinal */ 
tinclude <sys/dir.h> 


/* Tamanhos mínimos exigidos pelo padrão POSIX P1003.1 (Tabela 2-3). */ 


tifdef -POSIX SOURCE /* esses só são visíveis para o POSIX */ 
tdefine | POSIX ARG MAX 4096 /* exec() pode ter 4K de argumentos */ 
tdefine | POSIX CHILD MAX 6 /* um processo pode ter 6 filhos */ 
tdefine -POSIX LINK MAX 8 /* um arquivo pode ter 8 vínculos */ 


ádefine | POSIX MAX CANON 255 /* tamanho da fila de entrada canônica */ 
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00140 
00141 
00142 
00143 
00144 
00145 
00146 
00147 
00148 
00149 
00150 
00151 
00152 
00153 
00154 
00155 
00156 
00157 
00158 
00159 
00160 
00161 
00162 
00163 
00164 
00165 
00166 
00167 
00168 
00169 
00170 


define | POSIX MAX INPUT 255 
define . POSIX NAME MAX DIRSIZ 


#de 
#de 
#de 
#de 
#de 
#de 


#define _POSIX_SSIZE_MAX 32767 


você pode digitar 255 caracteres antecipadamente */ 

um nome de arquivo pode ter 14 caracteres */ 

as IDs de grupo complementares são opcionais */ 

* um processo pode ter 16 arquivos abertos */ 

um nome de caminho pode conter 255 caracteres */ 

as escritas em pipes de 512 bytes devem ser atômicas */ 
* pelo menos 8 arquivos podem ser abertos de uma vez */ 
* Nomes de fuso horário com pelo menos 3 caracteres */ 
read() deve suportar leituras de 32767 bytes */ 


fine -POSIX NGROUPS MAX O 
fine - POSIX OPEN MAX 16 
fine -POSIX PATH MAX 255 
fine POSIX PIPE BUF 512 
fine . POSIX STREAM MAX 8 
fine | POSIX TZNAME MAX 3 


SN rãs 


/* Valores realmente implementados pelo MINIX (Tabelas 2-4, 2-5, 2-6 e 2-7). */ 

/* Alguns desses nomes antigos devem ser melhor definidos quando não POSIX. */ 
ádefine NO LIMIT 100 /* número arbitrário; limite não imposto */ 

ádefine NGROUPS MAX O /* IDs de grupo suplementares não disponíveis */ 
ádefine ARG MAX 16384 /* número de bytes de args + ambiente para exec() */ 
tdefine CHILD MAX NO LIMIT /* o MINIX não limita os filhos */ 

#define OPEN_MAX 20 /* número de arquivos abertos que um processo pode ter */ 
#define LINK_MAX SHRT MAX /* número de vínculos que um arquivo pode ter */ 
#define MAX_CANON 255 /* tamanho da fila de entrada canônica */ 

#define MAX_INPUT 255 /* tamanho do buffer de antecipação de tipo */ 
#define NAME_MAX DIRSIZ /* número de caracteres em um nome de arquivo */ 
#define PATH_MAX 255 /* número de caracteres em um nome de caminho */ 
#define PIPE_BUF 7168 /* número de bytes na escrita atômica em um pipe */ 
#define STREAM_MAX 20 /* deve ser igual a FOPEN_MAX em stdio.h */ 

#define TZNAME_MAX 3 /* o máximo de bytes em um nome de fuso horário é 3 */ 
#define SSIZE_MAX 32767 /* contagem de byte máxima definida para readO */ 
#endif /* _POSIX_SOURCE */ 

#endif /* _LIMITS_H */ 


HEHEHEHEHE HHHH HHHH HHHH H+H HH HH H+H H+H HHHH HHHH H+H HHH H+H HHHH HHHH HHHH HHHH 


include/errno.h 


APAE H+H HH H+H HH HH HHE HH HHHH H+H HH HHHH H+H HHHH HHHH H+HHH+HH+H+HH+H+H+H+H+H+ 


00200 
00201 
00202 
00203 
00204 
00205 
00206 
00207 
00208 
00209 
00210 
00211 
00212 
00213 
00214 
00215 
00216 
00217 
00218 
00219 


/* 


O cabeçalho <errno.h> define os números dos vários erros que podem 

ocorrer durante a execução do programa. Eles são visíveis para programas de usuário e 
devem ser valores inteiros positivos pequenos. Entretanto, eles também são usados 
dentro do MINIX, onde devem ser negativos. Por exemplo, a chamada de sistema READ é 
executada internamente pela chamada do_read(). Esta função retorna um número de 

erro (negativo) ou o número (positivo) de bytes realmente lidos. 


Para resolver o problema de ter números de erro negativos dentro do 
sistema e positivos fora, o seguinte mecanismo é usado. Todas as 
definições são da forma: 


#define EPERM C SIGN 1) 
Se a macro SYSTEM for definida, então SIGN será configurada como "-":caso contrário, 
ela será configurada como "". Assim, ao compilar o sistema operacional, a macro SYSTEM 
será definida, configurando EPERM como (- 1), enquanto que, quando esse 
arquivo for incluído em um programa de usuário normal, EPERM terá o valor ( 1). 


tifndef - ERRNO H /* verifica se <errno.h> já está incluído */ 
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00220 &define ERRNO H /* não está incluído; anote esse fato */ 
00221 
00222 /* Agora define SIGN como "" ou "-", dependendo de SYSTEM. */ 


00223 #ifdef SYSTEM 

00224 # define SIGN - 
00225 # define OK 0 
00226 #else 

00227 # define SIGN 

00228 #endif 


00229 

00230 extern int errno; /* lugar onde ficam os números de erro */ 
00231 

00232 /* Aqui estão os valores numéricos dos números de erro. */ 

00233 define _NERROR 70 /* número de error */ 

00234 

00235 define EGENERIC C SIGN 99) /* erro genérico */ 

00236 gdefine EPERM (SIGN 1) /* operação não permitida */ 

00237 #define ENOENT C SIGN 2) /* não existe tal arquivo ou diretório */ 
00238 define ESRCH C SIGN 3) /* não existe tal processo */ 

00239 #define EINTR C SIGN 4) /* chamada de função interrompida */ 

00240 define EIO C SIGN 5) /* erros de entrada/saída */ 

00241 define ENXIO C SIGN 6) /* não existe tal dispositivo ou endereço */ 
00242 gdefine EZBIG (SIGN 7) /* lista de argumentos grande demais */ 
00243 define ENOEXEC C SIGN 8) /* erro de formato de exec */ 

00244 define EBADF C SIGN 9) /* descritor de arquivo defeituoso */ 

00245 define ECHILD C SIGN 10) /* não existe processo filho */ 

00246 #define EAGAIN (SIGN 11) /* recurso temporariamente indisponível */ 
00247 define ENOMEM C SIGN 12) /* sem espaço suficiente */ 

00248 #define EACCES C SIGN 13) /* permissão negada */ 

00249 #define EFAULT C SIGN 14) /* endereço defeituoso */ 

00250 #define ENOTBLK C SIGN 15) /* Extensão: não é um arquivo de bloco especial */ 
00251 #define EBUSY C SIGN 16) /* recurso ocupado */ 

00252 #define EEXIST C SIGN 17) /* o arquivo existe */ 

00253 #define EXDEV C SIGN 18) /* vínculo incorreto */ 

00254 define ENODEV C SIGN 19) /* não existe tal dispositivo */ 

00255 define ENOTDIR C SIGN 20) /* não é um diretório */ 

00256 define EISDIR C SIGN 21) /* é um diretório */ 

00257 define EINVAL C SIGN 22) /* argumento inválido */ 

00258 define ENFILE C SIGN 23) /* arquivos abertos demais no sistema */ 
00259 define EMFILE C SIGN 24) /* arquivos abertos demais */ 

00260 gdefine ENOTTY C SIGN 25) /* operação de controle de E/S inadequada */ 
00261 define ETXTBSY C SIGN 26) /* não é mais usado */ 

00262 #define EFBIG C SIGN 27) /* arquivo grande demais */ 

00263 #define ENOSPC (SIGN 28) /* não resta espaço no dispositivo */ 

00264 define ESPIPE C SIGN 29) /* busca inválida */ 

00265 define EROFS C SIGN 30) /* sistema de arquivos somente de leitura */ 
00266 define EMLINK C SIGN 31) /* vinculos demais */ 

00267 define EPIPE C SIGN 32) /* pipe danificado */ 

00268 #define EDOM C SIGN 33) /* erro de do (do C ANSI padrão) */ 

00269 #define ERANGE C SIGN 34) /* resultado grande demais (do C ANSI padrão) */ 
00270 #define EDEADLK C SIGN 35) /* impasse de recurso evitado */ 

00271 gdefine ENAMETOOLONG ( SIGN 36) /* nome de arquivo longo demais */ 

00272 define ENOLCK C SIGN 37) /* nenhuma trava disponível */ 

00273 #define ENOSYS C SIGN 38) /* função não implementada */ 

00274 define ENOTEMPTY C SIGN 39) /* diretório não vazio */ 

00275 

00276 /* Os erros a seguir se relacionam com interligação em rede. */ 

00277 #define EPACKSIZE C SIGN 50) /* tamanho de pacote inválido para algum protocolo */ 


00278 define EOUTOFBUFS (SIGN 51) /* não restam buffers suficientes */ 
00279 define EBADIOCTL C SIGN 52) /* ioctl inválido para o dispositivo */ 
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00280 
00281 
00282 
00283 
00284 
00285 
00286 
00287 
00288 
00289 
00290 
00291 
00292 
00293 
00294 
00295 
00296 
00297 
00298 
00299 
00300 
00301 
00302 
00303 
00304 
00305 
00306 
00307 
00308 
00309 
00310 
00311 
00312 
00313 
00314 


PARRA ++ 


HEHEHEHEHE HHHH HEHH H HH HE HH HHEH HHEH HH H+ HH ++ 


00400 
00401 
00402 
00403 
00404 
00405 
00406 
00407 
00408 
00409 
00410 
00411 
00412 
00413 
00414 
00415 
00416 
00417 
00418 
00419 


#define EBADMODE 
#define EWOULDBLOCK 
#define EBADDEST 
#define EDSTNOTRCH 
#define EISCONN 
#define EADDRINUSE 
#define ECONNREFUSED 
#define ECONNRESET 
#define ETIMEDOUT 
#define EURG 

#define ENOURG 
#define ENOTCONN 
#define ESHUTDOWN 
#define ENOCONN 
#define EAFNOSUPPORT 


#define EPROTOTYPE 
#define EINPROGRESS 


( SIGN 
( SIGN 
( SIGN 
( SIGN 
( SIGN 
( SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 


C SIGN 
C SIGN 


53) 
54) 
55) 
56) 
57) 
58) 
59) 
60) 
61) 
62) 
63) 
64) 
65) 
66) 
67) 


69) 
70) 


define EADDRNOTAVAIL ( SIGN 71) 


#define EALREADY 
ádefine EMSGSIZE 


/* Os seguintes não são erros do POSIX, mas ainda podem acontecer. 
* Todos eles são gerados pelo núcleo e se relacionam à passagem de mensagens. 


*/ 
#define ELOCKED 
#define EBADCALL 
#define EBADSRCDST 
#define ECALLDENIED 
#define EDEADDST 
#define ENOTREADY 
#define EBADREQUEST 
#define EDONTREPLY 


#endif /* _ERRNO_H */ 


/* O cabeçalho <unistd.h> contém algumas constantes de manifesto misturadas. * 


tifndef _UNISTD_H 
tdefine _UNISTD_H 


tifndef . TYPES H 


C SIGN 
C SIGN 


C SIGN 
C SIGN 
C SIGN 
C SIGN 
C SIGN 
(C SIGN 
C SIGN 
C SIGN 


tinclude <sys/types.h> 


gendi f 


72) 
73) 


101) 
102) 
103) 
104) 
105) 
106) 
107) 
201) 


/* badmode em ioctl */ 


/* não é um endereço de destino válido */ 


/* destino inacessível */ 
/* tudo pronto e conectado */ 
/* endereço em uso */ 

/* conexão recusada */ 

/* conexão reconfigurada */ 
/* conexão expirada */ 

/* dados urgentes presentes 
/* dados não urgentes presentes */ 


/* nenhuma conexão (ainda ou mais nenhuma) */ 

/* uma chamada write para uma desfazer conexão */ 
/* não existe tal conexão */ 

/* família de endereços não suportada */ 

gdefine EPROTONOSUPPORT ( SIGN 68) /* protocolo não suportado pelo AF */ 

/* tipo de protocolo errado para o soquete */ 

/* Operação em andamento agora */ 

/* Impossível atribuir endereço solicitado */ 


/* Conexão já em andamento */ 
/* Mensagem longa demais */ 


A E 


»* 


»* 


* 


SS a SS 


P 


include/unistd.h 


/* Valores usados por access(). Tabela 2-8 do 


#define F OK 
#define X OK 
#define W OK 
#define R OK 


/* Valores usados por whence em Tseek(fd, offset, whence). Tabela 2-9 do POSIX. * 


ádefine SEEK SET 
tdefine SEEK CUR 
tdefine SEEK END 


0 
1 
2 
4 
0 


1 
2 


/* testa se 
/* testa se 
/* testa se 
/* testa se 


o 


o 
(o) 
o 


POSIX. */ 


arquivo 
arquivo 
arquivo 
arquivo 


existe 


legível 


*/ 
é executável 
é gravável*/ 


*/ 


*/ 


/* o deslocamento é absoluto */ 


/* o deslocamento é relativo à posição corrente */ 
/* o deslocamento é relativo ao final do arquivo */ 


* impossível enviar mensagem devido a impasse */ 
* número de chamada de sistema inválido */ 

* processo de origem ou destino danificado */ 

* não tem permissão para a chamada de sistema */ 
* destino do envio não está ativo */ 

* origem ou destino não está pronto */ 

* o destino não pode manipular o pedido */ 

* pseudo-código: não envia uma resposta */ 


*/ 
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00420 
00421 
00422 
00423 
00424 
00425 
00426 
00427 
00428 
00429 
00430 
00431 
00432 
00433 
00434 
00435 
00436 
00437 
00438 
00439 
00440 
00441 
00442 
00443 
00444 
00445 
00446 
00447 
00448 
00449 
00450 
00451 
00452 
00453 
00454 
00455 
00456 
00457 
00458 
00459 
00460 
00461 
00462 
00463 
00464 
00465 
00466 
00467 
00468 
00469 
00470 
00471 
00472 
00473 
00474 
00475 
00476 
00477 
00478 
00479 


/* Este valor é exigido pela Tabela 2-10 do POSIX. */ 
#define . POSIX VERSION 199009L /* qual padrão está sendo obedecido */ 


/* Estas três definições são exigidas pela Seção 8.2.1.2 do POSIX. */ 
/* descritor de arquivo para stdin */ 
/* descritor de arquivo para stdout */ 
/* descritor de arquivo para stderr */ 


define STDIN FILENO 
define STDOUT FILENO 
define STDERR FILENO 


tifdef _MINIX 

/* Como sair do sistema ou 
tdefine RBT HALT 

tdefine RBT REBOOT 
tdefine RBT PANIC 

tdefine RBT MONITOR 
tdefine RBT RESET 

#endif 


0 
1 
2 


interoómper um processo servidor. */ 


AUNBEO 


/* um servidor entra em pânico */ 
/* permite que o monitor faça isso */ 
reconfiguração incondicional do sistema */ 


/* 


/* Quais informações de sistema recuperar com sysgetinfoO. */ 


tdefine SI KINFO 

tdefine SI PROC ADDR 
tdefine SI PROC TAB 
tdefine SI DMAP TAB 


0 


1 
2 
3 


`N aay 


* obtém informações do núcleo via GP */ 

* endereço da tabela de processos */ 

* cópia da tabela de processos inteira */ 

* obtém mapeamentos de dispositivo <-> driver */ 


/* NULL deve ser definido em <unistd.h>, de acorco com a Seção 2.7.1 do POSIX. */ 
#define NULL (Cvoid *)0) 


/* Variáveis de sistema que podem ser configuradas . Tabela 4-2 do POSIX. */ 


#define _SC_ARG_MAX 
#define _SC_CHILD_MAX 


1 
2 


#define _SC_CLOCKS_PER_SEC 3 


#define _SC_CLK_TCK 
#define _SC_NGROUPS_MAX 
#define _SC_OPEN_MAX 
#define _SC_JOB_CONTROL 
#define _SC_SAVED_IDS 
#define _SC_VERSION 
#define _SC_STREAM_MAX 
#define _SC_TZNAME_MAX 


/* Variáveis de nome de caminho 


#define _PC_LINK_MAX 
#define _PC_MAX_CANON 
#define _PC_MAX_INPUT 
#define _PC_NAME_MAX 
#define _PC_PATH_MAX 
#define _PC_PIPE_BUF 
#define _PC_NO_TRUNC 
#define _PC_VDISABLE 


#define _PC_CHOWN_RESTRICTED 9 


/* O POSIX define várias opções 


DONOS U sw 


H 
© 


1 


2 
3 
4 
5 
6 
7 
8 


/* 


N 


/* 
/* 
/* 
/* 
/* 
/* 
/* 


que podem ser configuradas. Tabela 5-2 do POSIX. */ 


contador de vínculos */ 


* tamanho da 


tamanho de 
tamanho de 
tamanho de 
tamanho de 
tratamento 


fila de entrada canônica */ 
buffer de tipo antecipado */ 
nome de arquivo */ 

nome de caminho */ 

pipe */ 

de componentes de nome longo */ 


desativar tty */ 
chown restrito ou não */ 


que podem ou não ser implementadas, de acordo 


* com o implementador. Este implementador fez as seguintes escolhas: 


*  POSIX JOB CONTROL 
-POSIX SAVED IDS 
-POSIX NO TRUNC 
*  POSIX CHOWN RESTRICTED 
*  POSIX VDISABLE 
a, 
define . POSIX NO TRUNC 


+ 


5 


não definido: 

não definido: 
definido como -1: 
definido: 
definido: 


CH 


nenhum controle de tarefa 

nenhum uid/gid salvo 

os nomes de caminho longos são truncados 
você não pode desfazer-se de arquivos 

as funções tty podem ser desativadas 
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00480 
00481 
00482 
00483 
00484 
00485 
00486 
00487 
00488 
00489 
00490 
00491 
00492 
00493 
00494 
00495 
00496 
00497 
00498 
00499 
00500 
00501 
00502 
00503 
00504 
00505 
00506 
00507 
00508 
00509 
00510 
00511 
00512 
00513 
00514 
00515 
00516 
00517 
00518 
00519 
00520 
00521 
00522 
00523 
00524 
00525 
00526 
00527 
00528 
00529 
00530 
00531 
00532 
00533 
00534 
00535 
00536 
00537 
00538 
00539 


define . POSIX CHOWN RESTRICTED 1 


/* Prototypes de Função */ 


- PROTOTYPEC 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 


_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 
_PROTOTYPE( 


void _exit, (int _status) 

int access, (const char *_path, int _amode) 
unsigned int alarm, (unsigned int _seconds) 
int chdir, (const char *_path) 

int fchdir, (Cint fd) 


int chown, (const char *_path, _mnx_Uid_t _owner, _mnx_Gid_t _group) 


); 


int close, (int fd) 

char *ctermid, (char *_s) 
char *cuserid, (char *_s) 

int dup, Cint fd) 

int dup2, (Cint fd, int fd2) 


int execl, (const char * path, const char * arg, ...) 
int execle, (const char * path, const char * arg, ...) 
int execlp, (const char * file, const char *arg, ...) 
int execv, (const char * path, char *const argv[]) 


int execve, (const char * path, char *const argv[], 


char *const _envp[]) 


int execvp, (const char * file, char *const argv[]) 
pid t fork, (void) 

long fpathconf, (int fd, int name) 

char *getcwd, (char * buf, size t size) 

gid t getegid, (void) 

uid t geteuid, (void) 

gid t getgid, (void) 

int getgroups, (int gidsetsize, gid t grouplist[]) 
char *getlogin, (void) 

pid t getpgrp, (void) 

pid t getpid, (void) 

pid t getppid, (void) 

uid t getuid, (void) 

int isatty, (int fd) 

int link, (const char * existing, const char * new) 
off t Iseek, (int fd, off t offset, int whence) 
long pathconf, (const char * path, int name) 

int pause, (void) 

int pipe, Cint fildes[2]) 

ssize t read, (int fd, void * buf, size_t _n) 

int rmdir, (const char * path) 

int setgid, Cmnx Gid t gid) 

int setpgid, (pid_t pid, pidt pgid) 

pid t setsid, (void) 

int setuid, Cmnx Uid t uid) 

unsigned int sleep, (unsigned int seconds) 

long sysconf, (int name) 

pid t tcgetpgrp, (int fd) 

int tcsetpgrp, (int fd, pidt pgrp id) 

char *ttyname, (int fd) 

int unlink, (const char * path) 

ssize t write, (int fd, const void * buf, size_t n) 


/* Open Group Base Specifications Issue 6 (incompleto) */ 


- PROTOTYPE( 
- PROTOTYPE( 
extern char 


int symlink, (const char *path1l, const char *path2) 
int getopt, (int argc, char ** argv, char * opts) 
*optarg; 


extern int optind, opterr, optopt; 


- PROTOTYPEC 


int usleep, (useconds t useconds) 


J3 


2 


592 


SISTEMAS OPERACIONAIS 


00540 
00541 
00542 
00543 
00544 
00545 
00546 
00547 
00548 
00549 
00550 
00551 
00552 
00553 
00554 
00555 
00556 
00557 
00558 
00559 
00560 
00561 
00562 
00563 
00564 
00565 
00566 
00567 
00568 
00569 
00570 
00571 
00572 
00573 
00574 
00575 
00576 
00577 
00578 
00579 
00580 
00581 
00582 
00583 


#ifdef _MINIX 
#ifndef _TYPE_H 
#include <minix/type.h> 


#endif 
- PROTOTYPEC int brk, (char *_addr) ); 
_PROTOTYPE(Ç int chroot, (const char * name) js 


- PROTOTYPE( int mknod, (const char * name, mnx Mode t mode, Dev t addr) 
- PROTOTYPE( int mknod4, (const char * name, mnx Mode t mode, Dev t addr, 
long size) i 
- PROTOTYPE( char *mktemp, (char * template) js 
- PROTOTYPE( int mount, (char * spec, char * name, int flag) J 
- PROTOTYPE( long ptrace, (int reg, pid_t pid, long _addr, long data) ); 
_PROTOTYPE(Ç char *sbrk, (int _incr) E 


- PROTOTYPE( int sync, (void) J; 
_PROTOTYPEÇ int fsync, (int fd) Ji 
- PROTOTYPE( int umount, (const char * name) Je 
_PROTOTYPE(Ç int reboot, (int how, ...) Js 


_PROTOTYPE(Ç int gethostname, (char * hostname, size_t Ten) ) 
- PROTOTYPE( int getdomainname, (char * domain, size_t Ten) ) 
- PROTOTYPE( int ttyslot, (void) ) 
_PROTOTYPE(Ç int fttyslot, (int fd) ) 
- PROTOTYPE( char *crypt, (const char *_key, const char * salt) J 
- PROTOTYPE( int getsysinfo, (int who, int what, void *where) J 
- PROTOTYPE( int getprocnr, (void) ) 
_PROTOTYPE(Ç int findproc, (char *proc name, int *proc_nr) ) 
- PROTOTYPE( int allocmem, (phys_bytes size, phys bytes *base) ) 
- PROTOTYPE( int freemem, (phys_bytes size, phys bytes base) ) 
#define DEV_MAP 1 

#define DEV_UNMAP 2 


#define mapdriver(driver, device, style) devctl(DEV_MAP, driver, device, style) 


#define unmapdriver(device) devctI(DEV UNMAP, O, device, 0) 
- PROTOTYPE( int devctl, (int ctl req, int driver, int device, int style)); 


/* Para compatibilidade com outros sistemas Unix */ 


- PROTOTYPE( int getpagesize, (void) Js 
- PROTOTYPE( int setgroups, (int ngroups, const gid_t *gidset) Ji 
#endif 


_PROTOTYPE(Ç int readlink, (const char *, char *, int)); 
- PROTOTYPE( int getopt, (int, char **, char *)); 
extern int optind, opterr, optopt; 


gendif /*  UNISTD H */ 


AAA ++ 


include/string.h 


AAA ++ 


00600 
00601 
00602 
00603 
00604 
00605 
00606 
00607 
00608 
00609 


/* O cabeçalho <string.h> contém prototypes para as funções de tratamento 
* de string. 


*/ 


#ifndef _STRING_H 
#define _STRING_H 


#define NULL (Cvoid *)0) 


#ifndef _SIZE_T 


J; 
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00610 
00611 
00612 
00613 
00614 
00615 
00616 
00617 
00618 
00619 
00620 
00621 
00622 
00623 
00624 
00625 
00626 
00627 
00628 
00629 
00630 
00631 
00632 
00633 
00634 
00635 
00636 
00637 
00638 
00639 
00640 
00641 
00642 
00643 
00644 
00645 
00646 
00647 
00648 
00649 
00650 
00651 
00652 
00653 
00654 
00655 
00656 
00657 
00658 
00659 
00660 
00661 
00662 
00663 
00664 


tdefine SIZE T 
typedef unsigned int size t; /* tipo retornado por sizeof * 
#endif /* SIZE T */ 


/* Prototypes de Função. */ 
tifndef | ANSI H 

tinclude <ansi.h> 

#endif 


_PROTOTYPE(Ç void *memchr, (const void *_s, int _c, size_t 


- PROTOTYPE( int memcmp, (const void *_s1, const void *_s2, 


/ 


n) 


size_t n) 


- PROTOTYPE( void *memcpy, (void * sl, const void * s2, size_t n) 
“ PROTOTYPE( void *memmove, (void * sl, const void * s2, size_t n) 


“ PROTOTYPE( void *memset, (void * s, int c, size_t n) 
- PROTOTYPE( char *strcat, (char * sl, const char * s2) 
- PROTOTYPE( char *strchr, (const char * s, int _c) 


- PROTOTYPE( int strncmp, (const char * sl, const char * s2, size_t n) 


- PROTOTYPE( int strcmp, (const char * sl, const char * s2) 
- PROTOTYPE( int strcoll, (const char * sl, const char * s2) 
- PROTOTYPE( char *strcpy, (char * sl, const char * s2) 


- PROTOTYPE( size_t strcspn, (const char * sl, const char *. 


“ PROTOTYPE( char *strerror, (int | errnum) 
- PROTOTYPE( size_t strlen, (const char * s) 


s2) 


- PROTOTYPE( char *strncat, (char * sl, const char * s2, size_t n) 
- PROTOTYPE( char *strncpy, (char * sl, const char * s2, size_t n) 
- PROTOTYPE( char *strpbrk, (const char * sl, const char * s2) 


- PROTOTYPE(C char *strrchr, (const char *_s, int Cc) 


- PROTOTYPE( size_t strspn, (const char * sl, const char * s2) 


- PROTOTYPE( char *strstr, (const char * sl, const char * s2 
- PROTOTYPE( char *strtok, (char * sl, const char * s2) 
- PROTOTYPE( size_t strxfrm, (char * sl, const char * s2, si 


Hifdef -POSIX SOURCE 

/* Open Group Base Specifications Issue 6 (incompleto) */ 
char *strdup(const char * sl); 

Hendif 


tifdef _MINIX 

/* Para compatibilidade com versões anteriores. */ 

“ PROTOTYPE( char *index, (const char * s, int _charwanted) 
“ PROTOTYPE( char *rindex, (const char * s, int _charwanted) 


- PROTOTYPE( void bcopy, (const void * src, void * dst, size_t length) 


J 


zet n) 


IF 
J3 
); 


_PROTOTYPE(Ç int bcmp, (const void *_s1, const void * s2, size_t _length) ); 


- PROTOTYPE( void bzero, (void * dst, size_t _length) 


); 


- PROTOTYPE( void *memccpy, (char * dst, const char * src, int _ucharstop, 


size t size) 
/* Funções extras misturadas */ 
- PROTOTYPE( int strcasecmp, (const char * sl, const char * s2) 
- PROTOTYPE( int strncasecmp, (const char * sl, const char * s2, 


size_t _len) 


_PROTOTYPE( size_t strnlen, (const char *_s, size_t _n) 
#endif 


#endif /* _STRING_H */ 


); 


J3 


); 
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DO soa espa o O HHHH HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O O DO OO OO O RS 
include/signal.h 
DO one oo o o a O O HHHH HHHH HHHH HHHH HHHH HH H+H HH HHHH HHHH O O O O SD DO OO OO O O 


00700 /* O cabeçalho <signal.h> define todos os sinais ANSI e POSIX. 


00701 * O MINIX suporta todos os sinais exigidos pelo POSIX. Eles estão definidos abaixo. 
00702 * Alguns sinais adicionais também são suportados. 

00703 */ 

00704 


00705 #ifndef _SIGNAL_H 

00706 #define _SIGNAL_H 

00707 

00708 #ifndef _ANSI_H 

00709 #include <ansi.h> 

00710 #endif 

00711 &ifdef | POSIX SOURCE 
00712 &ifndef TYPES H 

00713 include <sys/types.h> 
00714 #endif 

00715 #endif 

00716 

00717 /* Aqui estão os tipos intimamente associados ao tratamento de sinais. */ 
00718 typedef int sig atomic t; 
00719 

00720 #ifdef | POSIX SOURCE 
00721 &ifndef | SIGSET T 

00722 &define SIGSET T 

00723 typedef unsigned long sigset t; 
00724 #endif 

00725 #endif 


00726 

00727 #define NSIG 20 /* número de sinais usados */ 

00728 

00729 define SIGHUP 1 /* desliga */ 

00730 #define SIGINT 2 /* interrupção (DEL) */ 

00731 #define SIGQUIT 3 /* sai (ASCII FS) */ 

00732 #define SIGILL 4 /* instrução inválida */ 

00733 define SIGTRAP 5 /* trap de rastreamento (não reconfigura se capturado) */ 
00734 define SIGABRT 6 /* instrução IOT */ 

00735 #define SIGIOT 6 /* SIGABRT para pessoas que falam PDP-11 */ 

00736 define SIGUNUSED 7 /* código sobressalente */ 

00737 #define SIGFPE 8 /* exceção de ponto flutuante */ 

00738 gdefine SIGKILL 9 /* elimina (não pode ser capturado nem ignorado) */ 
00739 define SIGUSR1 10 /* sinal definido pelo usuário # 1 */ 

00740 #define SIGSEGV 11 /* violação de segmentação */ 

00741 define SIGUSR2Z 12 /* sinal definido pelo usuário # 2 */ 

00742 #define SIGPIPE 13 /* escreve em um pipe sem ninguém para ler */ 

00743 define SIGALRM 14 /* despertador */ 

00744 define SIGTERM 15 /* sinal de término de software kill */ 

00745 #define SIGCHLD i7 /* processo filho terminou ou parou */ 

00746 

00747 #define SIGEMT 7 /* obsoleto */ 

00748 define SIGBUS 10 /* obsoleto */ 

00749 

00750 /* Sinais específicos do MINIX. Esses sinais não são usados por processos de usuário, 
00751 * mas se destinam a informar processos de sistema, como o MP, sobre eventos de sistema. 
00752 */ 

00753 #define SIGKMESS 18 /* nova mensagem de núcleo */ 


00754 #define SIGKSIG 19 /* sinal de núcleo pendente */ 
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00755 define SIGKSTOP 20 /* desligamento do núcleo */ 

00756 

00757 /* O POSIX exige que os seguintes sinais sejam definidos, mesmo que não 
00758 * sejam suportados. Aqui estão as definições, mas elas não são suportadas. 
00759 y 

00760 #define SIGCONT 18 /* continua, se for parado */ 

00761 #define SIGSTOP 19 /* sinal de parada */ 

00762 #define SIGTSTP 20 /* sinal de parada interativo */ 

00763 #define SIGTTIN 21 /* processo de segundo plano quer ler */ 
00764 #define SIGTTOU 22 /* processo de segundo plano quer escrever */ 
00765 


00766 /* O tipo sighandler_t não é permitido, a menos que _POSIX_SOURCE seja definido. */ 
00767 typedef void _PROTOTYPE(Ç (*__sighandler_t), Cint) ); 


00768 

00769 /* Macros usadas como ponteiros de função. */ 

00770 &define SIG ERR (CC sighandler t) -1) /* retorno de erro */ 

00771 &define SIG DFL (C sighandler t) 0) /* tratamento de sinal padrão */ 
00772 define SIG IGN (C sighandler t) 1) /* ignora sinal */ 

00773 #define SIG HOLD (C sighandler t) 2) /* bloqueia sinal */ 

00774 ádefine SIG CATCH ((. sighandler t) 3) /* captura signal */ 

00775 define SIG MESS (C sighandler t) 4) /* passa como mensagem (MINIX) */ 
00776 


00777 #ifdef | POSIX SOURCE 
00778 struct sigaction { 


00779 — sighandler t sa handler; /* SIG DFL, SIG IGN ou ponteiro para função */ 

00780 sigset t sa mask; /* sinais a serem bloqueados durante rot. de tratamento */ 
00781 int sa flags; /* flags especiais */ 

00782 5; 

00783 


00784 /* Campos para sa flags. */ 


00785 define SA ONSTACK 0x0001 /* envia sinal na pilha alternativa */ 

00786 define SA RESETHAND 0x0002 /* reconfigura rot. de trat. de sinal quando capturado */ 
00787 gdefine SA NODEFER 0x0004 /* não bloqueia sinal enquanto o captura */ 
00788 define SA RESTART 0x0008 /* reinicia chamada de sistema automática */ 
00789 define SA SIGINFO 0x0010 /* tratamento de sinal estendido */ 

00790 define SA NOCLDWAIT 0x0020 /* não cria zumbis */ 

00791 gdefine SA NOCLDSTOP 0x0040 /* não recebe SIGCHLD quando o filho pára */ 
00792 

00793 /* O POSIX exige esses valores para uso com sigprocmask(2). */ 

00794 gdefine SIG BLOCK 0 /* para bloquear sinais */ 

00795 gdefine SIG UNBLOCK 1 /* para desbloquear sinais */ 

00796 gdefine SIG SETMASK 2 /* para configurar a máscara do sinal */ 
00797 #define SIG INQUIRE 4 /* apenas para uso interno */ 

00798 gendif /* | POSIX SOURCE */ 

00799 

00800 /* prototypes de função POSIX e ANSI. */ 

00801 | PROTOTYPE( int raise, (int sig) Jj; 
00802 | PROTOTYPE(C | sighandler t signal, (int sig, _ sighandler t func) J 
00803 

00804 #ifdef _POSIX_SOURCE 

00805 _PROTOTYPEÇ int kill, (pid_t _pid, int sig) Ji 
00806 _PROTOTYPEÇ int sigaction, 

00807 Cint sig, const struct sigaction * act, struct sigaction * oact) : 


) 
00808 | PROTOTYPE( int sigaddset, (sigset t * set, int sig) ) 
00809 _PROTOTYPEÇ int sigdelset, (sigset_t * set, int sig) J 
00810 | PROTOTYPE( int sigemptyset, (sigset t * set) ) 
00811 _PROTOTYPEÇ int sigfillset, (sigset_t *_set) ) 
00812 | PROTOTYPE( int sigismember, (const sigset_t *_set, int sig) J 
00813 _PROTOTYPEÇ int sigpending, (sigset_t *_set) ) 
00814 _PROTOTYPEÇ int sigprocmask, 
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00815 
00816 
00817 
00818 
00819 


Cint “how, const sigset t * set, sigset t * oset) ); 
-PROTOTYPEC int sigsuspend, (const sigset_t * sigmask) J5 
#endif 


#endif /* _SIGNAL_H */ 


HEHEHEHEH HEHH HHHH HHHH HH HH HHHH H+H HHHH HHHH ++ 


include/fcntl.h 


HHHEHHHHH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


00900 
00901 
00902 
00903 
00904 
00905 
00906 
00907 
00908 
00909 
00910 
00911 
00912 
00913 
00914 
00915 
00916 
00917 
00918 
00919 
00920 
00921 
00922 
00923 
00924 
00925 
00926 
00927 
00928 
00929 
00930 
00931 
00932 
00933 
00934 
00935 
00936 
00937 
00938 
00939 
00940 
00941 
00942 
00943 
00944 
00945 
00946 
00947 
00948 
00949 


/* O cabeçalho <fcntl.h> é necessário para as chamadas de sistema open) e fentiO, 
* as quais têm uma variedade de parâmetros e flags. Elas estão descritas aqui. 
* Os formatos das chamadas são: 
* open(path, oflag [,mode]) open a file 
* fcntlCfd, cmd [,arg]) get or set file attributes 


*/ 


#ifndef _FCNTL_H 
#define _FCNTL_H 


#ifndef _TYPES_H 
#include <sys/types.h> 
#endif 


/* Esses valores são usados para cmd em fcntl(). Tabela 6-1 do POSIX. */ 

#define F_DUPFD * descritor de arquivo duplicado */ 

tdefine F GETFD obtém flags do descritor de arquivo */ 

“define F SETFD configura flags do descritor de arquivo */ 

tdefine F GETFL * obtém flags de status do arquivo */ 

ádefine F SETFL * configura flags de status do arquivo */ 

tdefine F GETLK obtém informação de trava de registro */ 

tdefine F SETLK configura trava de registro */ 

ádefine F SETLKW * configura trava de registro; espera, se bloqueado */ 


JOW BUwWUNHO 
a 


/* Flags de descritor de arquivo usados para fcntl(). Tabela 6-2 do POSIX. */ 


tdefine FD CLOEXEC 1 /* fecha no flag exec para o terceiro arg de fcntl */ 
/* Valores de L type para trava de registro com fcntl(). Tabela 6-3 do POSIX. */ 
tdefine F RDLCK 1 /* trava compartilhada ou de leitura */ 

tdefine F WRLCK 2 /* trava exclusiva ou de escrita */ 

tdefine F UNLCK 3 /* desbloqueia */ 


/* Valores do flag O para open(). Tabela 6-4 do POSIX. */ 


tdefine O CREAT 00100 /* cria arquivo, se ele não existe */ 
tdefine O EXCL 00200 /* flag de uso exclusivo */ 

tdefine O NOCTTY 00400 /* não atribui um terminal de controle */ 
tdefine O TRUNC 01000 /* trunca o flag */ 


/* Flags de status de arquivo para open) e fentlIQO. Tabela 6-5 do POSIX. */ 


define O APPEND 02000 /* configura modo anexar */ 

define O NONBLOCK 04000 /* sem atraso */ 

/* Modos de acesso a arquivo para open() e fentI(). Tabela 6-6 do POSIX. */ 

#define O RDONLY 0 /* open(name, O RDONLY) abre somente para leitura */ 
tdefine O WRONLY 1 /* open(name, O WRONLY) abre somente para escrita */ 
#define O_RDWR 2 /* open(name, O_RDWR) abre para leitura/escrita */ 


/* Máscara para uso com os modos de acesso a arquivo. Tabela 6-7 do POSIX. */ 
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00950 define O ACCMODE 03 /* máscara para os modos de acesso a arquivo */ 
00951 
00952 /* Estrutura usada para travamento. Tabela 6-8 do POSIX. */ 
00953 struct flock 1 
00954 short 1 type; /* tipo: F RDLCK, F WRLCK ou F UNLCK */ 
00955 short 1 whence; /* flag para iniciar deslocamento */ 
00956 off t 1 start; /* deslocamento relativo, em bytes */ 
00957 off t 1 Ten; /* tamanho; se for O, então até EOF */ 
00958 pidtTpid; /* id de processo do proprietário da trava */ 
00959 5; 
00960 
00961 /* Prototypes de Função. */ 
00962 | PROTOTYPE( int creat, (const char * path, mnx Mode t mode) js 
00963 _PROTOTYPE(Ç int fcntl, (Cint _filedes, int cmd, ...) Jė 
00964 _PROTOTYPEÇ int open, (const char * path, int _oflag, ...) Jj; 
00965 
00966 #endif /* _FCNTL_H */ 
DO spa Do O o O O O HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHHH O O SD DO OO O O O 
include/termios.h 
HHHEHEHHHHHH EHHH DO HHHH HHHH HHHH HHH HHHH HHHH HHHH O O DD H+H O O DO OO OD O O 
01000 /* O cabeçalho <termios.h> é usado para controlar modos de tty. */ 
01001 
01002 &ifndef | TERMIOS H 
01003 ádefine TERMIOS H 
01004 
01005 typedef unsigned short tcflag t; 
01006 typedef unsigned char cc t; 
01007 typedef unsigned int speed t; 
01008 
01009 gdefine NCCS 20 /* tamanho do array cc c, algum espaço extra 
01010 * para extensões. */ 
01011 
01012 /* Principal estrutura de controle de terminal. Tabela 7-1 do POSIX. */ 
01013 struct termios { 
01014 tcflag t ciflag; /* modos de entrada */ 
01015 tcflag t c oflag; /* modos de saída */ 
01016 tcflag t c cflag; /* modos de controle */ 
01017 tcflag t c Tflag; /* modos locais */ 
01018 speed t c ispeed; /* velocidade de entrada */ 
01019 speed t c ospeed; /* velocidade de saída */ 
01020 Ec. t c ccINCESI: /* caracteres de controle */ 
01021 +; 
01022 
01023 /* Valores para mapa de bits c iflag de termios. Tabela 7-2 do POSIX. */ 
01024 #define BRKINT 0x0001 /* sinaliza interrupção na pausa */ 
01025 define ICRNL 0x0002 /* mapeia CR em NL na entrada */ 
01026 define IGNBRK 0x0004 /* ignora pausa */ 
01027 define IGNCR 0x0008 /* ignora CR */ 
01028 define IGNPAR 0x0010 /* ignora caracteres com erros de paridade */ 
01029 define INLCR 0x0020 /* mapeia NL em CR na entrada */ 
01030 define INPCK 0x0040 /* habilita verificação de paridade de entrada */ 
01031 &define ISTRIP 0x0080 /* mascara o 8º bit */ 
01032 define IXOFF 0x0100 /* habilita início/parada do controle de entrada */ 
01033 define IXON 0x0200 /* habilita início/parada do controle de saída */ 
01034 define PARMRK 0x0400 /* marca erros de paridade na fila de entrada */ 
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01035 
01036 
01037 
01038 
01039 
01040 
01041 
01042 
01043 
01044 
01045 
01046 
01047 
01048 
01049 
01050 
01051 
01052 
01053 
01054 
01055 
01056 
01057 
01058 
01059 
01060 
01061 
01062 
01063 
01064 
01065 
01066 
01067 
01068 
01069 
01070 
01071 
01072 
01073 
01074 
01075 
01076 
01077 
01078 
01079 
01080 
01081 
01082 
01083 
01084 
01085 
01086 
01087 
01088 
01089 
01090 
01091 
01092 
01093 
01094 


/* Valores para mapa de bits c oflag de termios. Seção 7.1.2.3 do POSIX. */ 
/* 


tdefine 


OPOST 


0x0001 


realiza processamento de saída */ 


/* Valores para mapa de bits c -cflag de termios. Tabela 7-3 do POSIX. */ 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


CLOCAL 
CREAD 
CSIZE 


CSTOPB 
HUPCL 

PARENB 
PARODD 


C55 
Cs6 
Cs7 
cs8 


0x0001 
0x0002 
0x000C 
0x0000 
0x0004 
0x0008 
0x000C 
0x0010 
0x0020 
0x0040 
0x0080 


q 


ignora linhas de status de modem */ 


/* habilita receptor */ 


Sra 


* número de bits por caractere */ 
* se CSIZE é CS5, os caracteres têm 5 bits * 
* se CSIZE é CS6, os caracteres têm 6 bits * 
* se CSIZE é CS7, os caracteres têm 7 bits * 
* se CSIZE é CS8, os caracteres têm 8 bits * 


ISIS 


envia 2 bits de parada se configurado; senão, 1 */ 
desliga no último fechamento */ 


* habilita paridade na saída */ 
* usa paridade ímpar se configurado; senão, par */ 


/* Valores para mapa de bits c Iflag de termios. Tabela 7-4 do POSIX. */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


ECHO 
ECHOE 
ECHOK 
ECHONL 
ICANON 
IEXTEN 
ISIG 
NOFLSH 
TOSTOP 


0x0001 
0x0002 
0x0004 
0x0008 
0x0010 
0x0020 
0x0040 
0x0080 
0x0100 


ade E 


* habilita eco de caracteres de entrada */ 

* ecoa ERASE como retrocesso */ 

* ecoa KILL */ 

* ecoa NL */ 

* entrada canônica (erase e kill habilitados) */ 
* habilita funções estendidas */ 


habilita sinais */ 
desabilita flush após interromper ou encerrar */ 


* envia SIGTTOU (controle de tarefa, não implementado */ 


/* Índices no array c cc. Valores padrão entre parênteses. Tabela 7-5 do POSIX. */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


tdefine 


VEOF 
VEOL 
VERASE 
VINTR 
VKILL 
VMIN 
VQUIT 
VTIME 
VSUSP 
VSTART 
VSTOP 


-POSIX VDISABLE 


O /* cc c[VEOF] = EOF char (CD) */ 
1 /* cc c[VEOL] = EOL char (undef) */ 
2 /* cc c[VERASE] = ERASE char (CH) */ 
3 /* cc c[VINTR] = INTR char (DEL) */ 
4 /* cc c[VKILL] = KILL char (CU) */ 
5 /* cc c[VMIN] = valor de MIN para temporizador */ 
6 /* cc c[VQUIT] = QUIT char (CN) */ 
7 /* cc c[VTIME] = valor de TIME para temporizador */ 
8 /* cc c[VSUSP] = SUSP (^Z, ignored) */ 
9 /* cc c[VSTART] = START char (°S) */ 
10 /* cc c[VSTOP] = STOP char (^Q) */ 
(cc t)OxFF /* Você não pode gerar este 


* caractere com teclados 'normais”. 

* Mas alguns teclados específicos de idioma 

* podem gerar OxFF. Parece que todos os 

* 256 são usados; portanto, cc t deve ser um valor 
*& short. 


17 


/* Valores para as configurações ge taxa de transmissão de dados. Tabela 7-6 do POSIX. */ 


#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 
#define 


0x0000 
0x1000 
0x2000 
0x3000 
0x4000 
0x5000 
0x6000 
0x7000 
0x8000 
0x9000 


FNNO 


* desliga a linha */ 


* 50 baud */ 


75 baud */ 


* 110 baud */ 
* 134,5 baud */ 
* 150 baud */ 
* 200 baud */ 


300 baud */ 


* 600 baud */ 
* 1200 baud */ 
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01095 
01096 
01097 
01098 
01099 
01100 
01101 
01102 
01103 
01104 
01105 
01106 
01107 
01108 
01109 
01110 
01111 
01112 
01113 
01114 
01115 
01116 
01117 
01118 
01119 
01120 
01121 
01122 
01123 
01124 
01125 
01126 
01127 
01128 
01129 
01130 
01131 
01132 
01133 
01134 
01135 
01136 
01137 
01138 
01139 
01140 
01141 
01142 
01143 
01144 
01145 
01146 
01147 
01148 
01149 
01150 
01151 
01152 
01153 
01154 


#define B1800 OxA000 /* 1800 baud */ 

#define B2400 0xB000 /* 2400 baud */ 

#define B4800 0xC000 /* 4800 baud */ 

#define B9600 0xD000 /* 9600 baud */ 

#define B19200 0xE000 /* 19200 baud */ 

#define B38400 0xF000 /* 38400 baud */ 

/* Ações opcionais de tcsetattr(). Seção 7.2.1.2 do POSIX. */ 

#define TCSANOW 1 /* alterações vigoram imediatamente */ 

tdefine TCSADRAIN 2 /* alterações vigoram após a saída estar pronta */ 
tdefine TCSAFLUSH 3 /* espera que a saída termine e descarrega a entrada * 
/* Valores de queue selector para tcflush(). Seção 7.2.2.2 do POSIX. */ 

tdefine TCIFLUSH ai /* descarrega dados de entrada acumulados */ 
#define TCOFLUSH 2 /* descarrega dados de saída acumulados */ 

#define TCIOFLUSH 3 /* descarrega dados de entrada e saída acumulados */ 


/* Valores de ação para tcflow(). Seção 7.2.2.2 do POSIX. */ 


tdefine TCOOFF 1 /* suspende a saída */ 

tdefine TCOON 2 /* reinicia a saída suspensa */ 

#define TCIOFF 3 /* transmite um caractere STOP na linha */ 
#define TCION 4 /* transmite um caractere START na linha */ 


/* Prototypes de Função. */ 
#ifndef _ANSI_H 

#include <ansi.h> 

#endif 


_PROTOTYPE(Ç int tcsendbreak, (int _fildes, int duration) 

_PROTOTYPE(Ç int tcdrain, (int _filedes) 

_PROTOTYPEÇ int tcflush, (int _filedes, int queue selector) 

_PROTOTYPE(Ç int tcflow, (int _filedes, int action) 

_PROTOTYPE( speed t cfgetispeed, (const struct termios * termios p) 

- PROTOTYPE( speed t cfgetospeed, (const struct termios * termios p) 

- PROTOTYPE( int cfsetispeed, (struct termios * termios p, speed t speed) 
- PROTOTYPE( int cfsetospeed, (struct termios * termios p, speed t speed) 
- PROTOTYPE( int tcgetattr, (int filedes, struct termios * termios p) 

- PROTOTYPE( int tcsetattr, N 

Cint filedes, int opt actions, const struct termios * termios p) 


tdefine cfgetispeed(termios p) (Ctermios p)->c ispeed) 
tdefine cfgetospeed(termios p) (Ctermios p)->c ospeed) 
#define cfsetispeed(termios p, speed) ((termios p)->c ispeed = (speed), 0) 
#define cfsetospeed(termios p, speed) ((termios p)->c ospeed = (speed), 0) 


#ifdef _MINIX 

/* Aqui estão as extensões locais do padrão POSIX para o Minix. Os programas 
* compatíveis com o Posix não são capazes de acessá-las e, portanto, só são 
* definidos quando um programa Minix é compilado. 


*/ 


/* Extensões para o mapa de bits c_iflag de termios. */ 
#define IXANY 0x0800 /* permite qualquer tecla para continuar a saída */ 


/* Extensões para o mapa de bits c_oflag de termios. Elas só são ativadas 
* se OPOST estiver ativado. */ 


#define ONLCR 0x0002 /* Mapeamento de NL para CR-NL na saída */ 
#define XTABS 0x0004 /* Expande tabulações em espaços */ 
#define ONOEOT 0x0008 /* descarta (^D) de EOT na saída) */ 
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01155 
01156 
01157 
01158 
01159 
01160 
01161 
01162 
01163 
01164 
01165 
01166 
01167 
01168 
01169 
01170 
01171 
01172 
01173 
01174 
01175 
01176 
01177 
01178 
01179 
01180 
01181 
01182 
01183 
01184 
01185 
01186 
01187 
01188 
01189 
01190 
01191 
01192 
01193 
01194 
01195 
01196 
01197 
01198 
01199 
01200 
01201 
01202 
01203 
01204 
01205 


/* Extensões para o mapa de bits c lflag de termios. */ 


#define LFLUSHO 0x0200 /* Descarrega a saída. */ 

/* Extensões para o array Cc cc. */ 

#define VREPRINT 11 /* cc c[VREPRINT] (^R) */ 

#define VLNEXT 12 /* cc c[VLNEXT] (CV) */ 

gdefine VDISCARD 13 /* cc c[VDISCARD] (%0) */ 

/* Extensões para configurações de taxa de transmissão de dados. */ 
#define B57600 0x0100 /* 57600 baud */ 

define B115200 0x0200 /* 115200 baud */ 


/* Estas são as configurações padrão usadas pelo núcelo e por 'stty sane’ */ 


#define TCTRL DEF (CREAD | CS8 | HUPCL) 

gdefine TINPUT. DEF CBRKINT | ICRNL | IXON | IXANY) 
gdefine TOUTPUT. DEF COPOST | ONLCR) 

#define TLOCAL DEF CISIG | IEXTEN | ICANON | ECHO | ECHOE) 
gdefine TSPEED DEF B9600 

#define TEOF. DEF Nao JE OD */ 

#define TEOL DEF -POSIX VDISABL 

#define TERASE. DEF NO” /* ^H */ 

#define TINTR DEF A JE CC */ 

#define TKILL DEF 25” ye OU */ 

#define TMIN DEF 1 

#define TQUIT DEF 34” JRR 

gdefine TSTART DEF 21” [EQ */ 

#define TSTOP DEF 23º [805 */ 

#define TSUSP DEF 327 [8 OZ */ 

#define TTIME DEF 0 

#define TREPRINT DEF “N22” /* ^R */ 

#define TLNEXT. DEF 26” /* V */ 


define TDISCARD DEF ’\17? /* "0 */ 


/* Tamanho da janela. Esta informação é armazenada no driver TTY, mas não é usada. 
* Isto pode ser usado por aplicativos baseados em tela, em um ambiente de janelas. 
* Os ioctls TIOCGWINSZ e TIOCSWINSZ podem ser usados para obter e configurar 
* essa informação. 


E, 

struct winsize 

{ 
unsigned short ws_row; * linhas, em caracteres */ 
unsigned short ws_col; /* colunas, em caracteres */ 
unsigned short ws_xpixel; /* tamanho horizontal, pixels */ 
unsigned short ws_ypixel; /* tamanho vertical, pixels */ 

J}; 


#endif /* _MINIX */ 


#endif /* _TERMIOS_H */ 
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HEHEHEHEH HHHH HHHH HH HH H+H H+ HHHH HH H+H HH HHHH HH HHH H+H HHHH HHHH HH+HHH+HH+H+HH+H+H+H+H+H+ 


01300 
01301 
01302 
01303 
01304 
01305 
01306 
01307 
01308 
01309 
01310 
01311 
01312 
01313 
01314 
01315 
01316 
01317 
01318 
01319 
01320 
01321 
01322 
01323 
01324 
01325 
01326 
01327 
01328 
01329 
01330 
01331 
01332 
01333 
01334 
01335 
01336 
01337 
01338 
01339 
01340 
01341 


01342 
01343 
01344 
01345 
01346 
01347 
01348 
01349 
01350 
01351 
01352 
01353 
01354 


/* Esta bib. preve funções genéricas para gerência de temporizadores de cão de guarda. 
* Operam sobre a fila de temporizadores do processo que as chamam. 
* Os temporizadores devem usar tempo absoluto para permitir ordenação. A biblioteca fornece: 


tmrs settimer: (Cre)configura um novo temporizador cão de guarda 
* tmrs clrtimer: remove um temporizador das duas filas de temporizadores 
* tmrs_exptimers: verifica temporizadores expirados e executa funções cão de guarda 


Autor: 

* Jorrit N. Herder <jnherderâcs.vu.nl> 

* Adatado de tmr settimer e tmr clrtimer em src/kernel/clock.c. 
Última modificação: 30 de setembro de 2004. 

*/ 


tifndef - TIMERS H 
tdefine _TIMERS_H 


#include <limits.h> 
tinclude <sys/types.h> 


struct timer; 
typedef void (*tmr func t)(struct timer *tp); 
typedef union { int ta int; long ta long; void *ta ptr; } tmr arg t; 


/* Uma variável timer t deve ser declarada para cada temporizador distinto a ser usado. 
* A função cão de guarda e o tempo de expiração são configurados automaticamente pela 
* função de biblioteca tmrs settimer, mas seu argumento não é. 


*/ 
typedef struct timer 
{ 
struct timer *tmr_next; /* o próximo em um encadeamento de temporizadores */ 
clock t tmr_exp_time; /* tempo de expiração */ 
tmr_func_t tmr_func; /* função a ser chamada quando expirado */ 
tmr_arg_t tmr_arg; /* argumento aleatório */ 
} timer_t; 


/* Usado quando o temporizador não está ativo. */ 

#define TMR_NEVER CCclock_t) -1 < 0) ? (Cclock t) LONG MAX) : ((clock t) -1) 
#undef TMR_NEVER 

#define TMR_NEVER CCclock_t) LONG MAX) 


/* Essas definições podem ser usadas para configurar ou obter dados de uma variável de 
temporizador. */ 

tdefine tmr arg(tp) (&Ctp)->tmr arg) 

tdefine tmr exp time(tp) (&C(tp)->tmr exp time) 


/* Os temporizadores devem ser inicializados uma vez, antes de serem usados. Cuidado 
* para não reinicializar um temporizador que esteja em uma lista de temporizadores, 
* senão o encadeamento será quebrado. 

*/ 
#define tmr inittimer(tp) (void)((tp)->tmr_exp_time = TMR NEVER, N 
Ctp)->tmr next = NULL) 


/* As seguintes funções genéricas de gerenciamento de temporizador estão disponíveis. 
* Elas podem ser usadas para operar nas listas de temporizadores. A adição de um 


* temporizador em uma lista trata de sua remoção automaticamente. 
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01355 
01356 
01357 
01358 
01359 
01360 
01361 
01362 


*/ 
- PROTOTYPE( clock t tmrs clrtimer, (timer t **tmrs, timer t *tp, clock t *new head) 
- PROTOTYPE( void tmrs exptimers, (timer t **tmrs, clock t now, clock t *new head) 
- PROTOTYPE( clock t tmrs settimer, (timer t **tmrs, timer t *tp, 
clock t exp time, tmr func t watchdog, clock t *new head) ); 


gendif /* TIMERS H */ 


HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH H+H+HH+HH+H+HH+H+H+H+H+H+ 


include/sys/types.h 


HEHEHEHEH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


01400 
01401 
01402 
01403 
01404 
01405 
01406 
01407 
01408 
01409 
01410 
01411 
01412 
01413 
01414 
01415 
01416 
01417 
01418 
01419 
01420 
01421 
01422 
01423 
01424 
01425 
01426 
01427 
01428 
01429 
01430 
01431 
01432 
01433 
01434 
01435 
01436 
01437 
01438 
01439 
01440 
01441 
01442 
01443 
01444 


/* O cabeçalho <sys/types.h> contém importantes definições de tipo de dados. 
* É considerada uma boa prática de programação utilizar essas definições, 


* em vez do tipo de base subjacente. Por convenção, todos os nomes de tipo terminam 


* com t. 


*/ 


#ifndef _TYPES_H 
#define _TYPES_H 


#ifndef _ANSI_H 
#include <ansi.h> 
#endif 


/* O tipo size_t contém todos os resultados do operador sizeof. À primeira vista, 
* parece óbvio que ele deve ser um valor int sem sinal, mas nem sempre esse é o 
* caso. Por exemplo, o MINIX-ST (68000) tem ponteiros de 32 bits e inteiros de 


* 16 bits. Quando alguém solicita o tamanho de uma estrutura ou array de 70K, o resultado 


Ea 


exige 17 bits para ser expresso; portanto, size t deve ser um tipo long. O tipo 

* ssize t é a versão com sinal de size t. 
A 

tifndef SIZE T 

tdefine SIZE T 

typedef unsigned int size t; 

Hendif 


tifndef - SSIZE T 
tdefine SSIZE T 
typedef int ssize t; 
#endif 


#ifndef _TIME_T 
#define _TIME_T 


typedef long time_t; /* tempo em seg. desde 1 janeiro de 1970 0000 GMT */ 


#endif 


#ifndef _CLOCK_T 

#define _CLOCK_T 

typedef long clock_t; /* unidade para contabilidade do sistema */ 
#endif 


#ifndef _SIGSET_T 

#define _SIGSET_T 

typedef unsigned long sigset_t; 
#endif 
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01445 
01446 
01447 
01448 
01449 
01450 
01451 
01452 
01453 
01454 
01455 
01456 
01457 
01458 
01459 
01460 
01461 
01462 
01463 
01464 
01465 
01466 
01467 
01468 
01469 
01470 
01471 
01472 
01473 
01474 
01475 
01476 
01477 
01478 
01479 
01480 
01481 
01482 
01483 
01484 
01485 
01486 
01487 
01488 
01489 
01490 
01491 
01492 
01493 
01494 
01495 
01496 
01497 
01498 
01499 
01500 
01501 
01502 
01503 
01504 


/* Open Group Base Specifications Issue 6 (incompletas) */ 


typedef Tong useconds t; /* Tempo em microssegundos */ 

/* Tipos usados em estruturas de dados de disco, i-node etc.. */ 

typedef short dev t; /* contém par de dispositivo (principal |secundário) */ 
typedef char gid t; /* id de grupo */ 

typedef unsigned long ino_t; /* número i-node (sistema de arquivos V3) */ 
typedef unsigned short mode_t; /* tipo de arquivo e bits de permissões */ 
typedef short nlink_t; /* número de vínculos em um arquivo */ 

typedef unsigned Tong off t; /* deslocamento dentro de um arquivo */ 

typedef int pidot; /* id de processo (deve ser com sinal) */ 
typedef short uid t; /* id de usuário */ 

typedef unsigned long zone_t; /* número da zona */ 

typedef unsigned long block_t; /* número do bloco */ 

typedef unsigned long bit_t; /* número do bit em um mapa de bits */ 

typedef unsigned short zonel_t; /* número da zona para sistemas de arquivos V1 */ 


typedef unsigned short bitchunk_t; /* coleção de bits em um mapa de bits */ 


typedef unsigned char u8_t; /* tipo de 8 bits */ 
typedef unsigned short ul6 t; /* tipo de 16 bits */ 
typedef unsigned long u32_t; /* tipo de 32 bits */ 
typedef char i8_t; /* tipo de 8 bits com sinal */ 
typedef short 116 t; /* tipo de 16 bits com sinal */ 
typedef Tong 32 t; /* tipo de 32 bits com sinal */ 


typedef struct { u32 t [2]; } u64 t; 


/* Os tipos a seguir são necessários porque o MINIX usa definições de função 

estilo K&R (para máxima portabilidade). Quando um valor short, como dev t, 

* é passado para uma função com uma definição K&R, o compilador o promove 

* automaticamente para um valor int. O prototype deve conter um valor int como parâmetro 
e não um valor short, pois um valor int é o que uma definição de função de estilo antigo 
espera. Assim, usar dev t em um prototype seria incorreto. Seria 

* suficiente apenas usar int nos prototypes, em vez de dev t, mas Dev t 

* é mais claro. 


*/ 
typedef int Dev t; 
typedef int “mnx Gid t; 
typedef int Nlink t; 
typedef int “mnx Uid t; 
typedef int US t; 
typedef unsigned long U32 t; 
typedef int I8 t; 
typedef int 126 t; 
typedef long 132 t; 


/* O C-ANSI torna a escrita da promoção de tipos sem sinal muito complicada. Quando 
* sizeof(short) == sizeof(int), não há promoção; portanto, o tipo permanece sem sinal. 
Quando o compilador não é ANSI, normalmente não há perda de entendimento do sinal, 
* e normalmente não existem prototypes; portanto o tipo promovido não importa. 
* O uso de tipos como Ino t é uma tentativa de usar valores int (que não são 
* promovidos), enquanto fornece informações para o leitor. 


*/ 


typedef unsigned long Ino t; 


Hif EM WSIZE == 
/*typedef unsigned int Ino t; Ino t tem agora 32 bits */ 
typedef unsigned int Zonel t; 
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01505 typedef unsigned int Bitchunk t; 
01506 typedef unsigned int U16 t; 
01507 typedef unsigned int mnx Mode t; 


01508 

01509 #else /* EM WSIZE == 4, or EM WSIZE undefined */ 

01510 /*typedef int Ino t; Ino t tem agora 32 bits */ 
01511 typedef int Zonel t; 

01512 typedef int Bitchunk t; 

01513 typedef int U16 t; 

01514 typedef int “mnx Mode t; 

01515 

01516 #endif /* EM WSIZE == 2, etc */ 

01517 


01518 /* Tipo de rotina de tratamento de sinal, por exemplo SIG IGN */ 
01519 typedef void PROTOTYPE( (*sighandler t), Cint) ); 
01520 

01521 /* Compatibilidade com outros sistemas */ 

01522 typedef unsigned char u char; 

01523 typedef unsigned short u short; 

01524 typedef unsigned int u int; 

01525 typedef unsigned Tong u long; 

01526 typedef char *caddr t; 

01527 

01528 gendif /* TYPES H */ 


DO o na Do O SD O DO H HHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH O O O DO OO OO O O 
include/sys/sigcontext.h 
HHHEHEHHHHHHH HH HHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH HHH H+ HHH DO DO O O O 


01600 #ifndef _SIGCONTEXT_H 
01601 #define _SIGCONTEXT_H 


01602 

01603 /* A estrutura sigcontext é usada pela chamada de sistema sigreturn(2). 

01604 * sigreturn() raramente é chamada por programas de usuário, mas é usada internamente 
01605 * pelo mecanismo de captura de sinal. 

01606 */ 

01607 


01608 &ifndef ANSI H 

01609 #include <ansi.h> 

01610 #endif 

01611 

01612 &ifndef  MINIX SYS CONFIG H 
01613 &include <minix/sys config.h> 
01614 #endif 

01615 

01616 #if Idefined( MINIX CHIP) 
01617 &include "error, configuration is not known” 
01618 #endif 


01619 

01620 /* A estrutura a seguir devem corresponder à estrutura stackframe s usada 

01621 * pelo código de troca de contexto do núcleo. Registradores em ponto flutuante devem ser 
01622 * adicionados em uma estrutura diferente. 

01623 */ 


01624 struct sigregs { 
01625 short sr gs; 
01626 short sr fs; 
01627 short sr es; 
01628 short sr ds; 
01629 int sr di; 
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01630 
01631 
01632 
01633 
01634 
01635 
01636 
01637 
01638 
01639 
01640 
01641 
01642 
01643 
01644 
01645 
01646 
01647 
01648 
01649 
01650 
01651 
01652 
01653 
01654 
01655 
01656 
01657 
01658 
01659 
01660 
01661 
01662 
01663 
01664 
01665 
01666 
01667 
01668 
01669 
01670 
01671 
01672 
01673 
01674 
01675 
01676 
01677 
01678 
01679 
01680 
01681 
01682 
01683 
01684 
01685 
01686 
01687 
01688 
01689 


int sr si; 

int sr bp; 

int sr st; /* topo da pilha - usado no núcleo */ 

int sr bx; 

int sr dx; 

int sr cx; 

int sr retreg; 

int sr retadr; /* endereço de retorno para quem chama save -- usado 
* no núcleo */ 

int sr pc; 

int sr cs; 

int sr psw; 

int sr sp; 

int sr ss; 


3; 


struct sigframe 1 /* quadro de pilha criado para processo sinalizado */ 
- PROTOTYPE( void (*sf retadr), (void) ); 
int sf signo; 
int sf code; 
struct sigcontext *sf scp; 
int sf fp; 
- PROTOTYPE( void (*sf retadr2), (void) ); 
struct sigcontext *sf scpcopy; 


J; 


struct sigcontext { 

int sc_flags; /* estado de sigstack a restaurar */ 
long sc mask; /* máscara de sinal a restaurar */ 
struct sigregs sc regs; /* conjunto de registros a restaurar */ 


3; 


ádefine sc gs sc regs.sr gs 

#define sc fs sc regs.sr fs 

#define sc es sc regs.sr es 

ádefine sc ds sc regs.sr ds 

tdefine sc di sc regs.sr di 

tdefine sc si sc regs.sr si 

#define sc fp sc regs.sr bp 

#define sc st sc regs.sr st /* topo da pilha -- usado no núcleo */ 

#define sc bx sc regs.sr bx 

#define sc dx sc regs.sr dx 

#define sc cx sc regs.sr cx 

#define sc retreg sc regs.sr retreg 

#define sc retadr sc regs.sr retadr /* endereço de retorno para quem chama 
save -- usado no núcleo */ 

ádefine sc pc sc regs.sr pc 

#define sc cs sc regs.sr cs 

#define sc psw sc regs.sr psw 

#define sc sp sc regs.sr sp 

#define sc ss sc regs.sr ss 


/* Valores de sc flags. Devem concordar com <minix/jmp buf.h>. */ 

tdefine SC SIGCONTEXT 2 /* diferente de zero quando é incluído contexto de sinal */ 

tdefine SC NOREGLOCALS 4 /* diferente de zero quando os registradores não devem 
ser salvos e restaurados */ 


- PROTOTYPEC int sigreturn, (struct sigcontext * scp) J3 


#endif /* _SIGCONTEXT_H */ 
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AAA 
include/sys/stat.h 
DO spa Do O o O O +EH HH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O SD DO OO OO O O 


01700 /* O cabeçalho <sys/stat.h> define uma estrutura usada nas funções stat() e 


01701 * fstat. As informações dessa estrutura vêm do i-node de 

01702 * algum arquivo. Essas chamadas são a única maneira aprovada de inspecionar i-nodes. 
01703 */ 

01704 


01705 #ifndef _STAT_H 

01706 #define _STAT_H 

01707 

01708 #ifndef _TYPES_H 

01709 #include <sys/types.h> 
01710 #endif 


01711 

01712 struct stat { 

01713 dev t st dev; /* número de dispositivo principal/secundário */ 
01714 ino t st ino; /* número do i-node */ 

01715 mode t st mode; /* modo de arquivo, bits de proteção etc. */ 
01716 short int st nlink; /* & links; HACK TEMPORÁRIO: deve ser nlink t*/ 
01717 uid t st uid; /* uid do proprietário do arquivo */ 

01718 short int st gid; /* gid; HACK TEMPORÁRIO: deve ser gid t */ 

01719 dev t st rdev; 

01720 off t st size; /* tamanho do arquivo */ 

01721 time t st atime; /* hora do último acesso */ 

01722 time t st mtime; /* hora da última modificação de dados */ 

01723 time t st ctime; /* hora da última alteração de status de arquivo */ 
01724 3; 

01725 


01726 /* Definições de máscara tradicionais para st mode. */ 

01727 /* As conversões horríveis em apenas algumas das definições são para evitar extensões 
01728 * de sinal inesperadas, como S IFREG != (mode t) S IFREG quando os inteiros são de 32 bits. 
01729 */ 


01730 #define S IFMT ((mode_t) 0170000) /* tipo de arquivo */ 
01731 #define S_IFLNK ((mode_t) 0120000) /* vínculo simbólico, não implementado */ 
01732 define S_IFREG ((mode_t) 0100000) /* normal */ 

01733 #define S_IFBLK 0060000 /* bloco especial */ 

01734 #define S_IFDIR 0040000 /* diretório */ 

01735 #define S_IFCHR 0020000 /* caractere especial */ 

01736 #define S_IFIFO 0010000 /* isto é um FIFO */ 

01737 #define S ISUID 0004000 /* configura id de usuário na execução */ 
01738 define S ISGID 0002000 /* configura id de grupo na execução */ 
01739 /* o próximo é reservado para uso futuro */ 
01740 &define S ISVTX 01000 /* salva texto trocado mesmo após o uso */ 
01741 

01742 /* máscaras do POSIX para st mode. */ 

01743 #define S IRWXU 00700 /* proprietário: rwx------ */ 

01744 gdefine S IRUSR 00400 /* proprietário: r-------- */ 

01745 gdefine S IWUSR 00200 /* proprietário: -w------ */ 

01746 #define S IXUSR 00100 /* proprietário: --x------ */ 

01747 

01748 gdefine S IRWXG 00070 /* grupo: ---rwx--- */ 

01749 gdefine S IRGRP 00040 /* grupo: ---r----- */ 

01750 #define S IWGRP 00020 /* grupo! ----w---- */ 

01751 #define S IXGRP 00010 /* grupo: ----- x--- */ 

01752 

01753 #define S IRWXO 00007 /* outros: ------ rwx */ 

01754 #define S IROTH 00004 /* outros: ------ r-- */ 
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01755 #define S IWOTH 00002 /* outros: ------- w- */ 
01756 define S IXOTH 00001 /* outros: -------- x */ 
01757 


01758 /* As macros a seguir testam st mode (da Seção 5.6.1.1 do POSIX). */ 


01759 &define S ISREG(m) CCC(m) & S IFMT) == S IFREG) /* é um arquivo regular */ 
01760 &define S ISDIRC(m) CCC(m) & S IFMT) == S IFDIR) /* é um diretório */ 

01761 &define S ISCHR(m) CCm) & S IFMT) == S IFCHR) /* é um caractere especial */ 
01762 &define S ISBLK(m) (C(m) & S IFMT) == S IFBLK) /* é um bloco especial */ 
01763 &define S ISFIFOC(m) CCC(m) & S IFMT) == S IFIFO) /* é um pipe/FIFO */ 

01764 define S ISLNK(m) CCC(m) & S IFMT) == S IFLNK) /* é um vínculo simbólico */ 
01765 

01766 /* Prototypes de Função. */ 

01767 | PROTOTYPE( int chmod, (const char * path, mnx Mode t mode) js 

01768 _PROTOTYPE(Ç int fstat, (int _fildes, struct stat *_buf) js 

01769 _PROTOTYPE(Ç int mkdir, (const char *_path, _mnx_Mode_t mode) J; 

01770 _PROTOTYPEÇ int mkfifo, (const char *_path, _mnx_Mode_t _mode) J 

01771 _PROTOTYPEÇ int stat, (const char * path, struct stat * buf) ys 

01772 _PROTOTYPE( mode_t umask, (_mnx_Mode_t _cmask) Js 

01773 

01774 /* Open Group Base Specifications Issue 6 (incompletas) */ 

01775 _PROTOTYPEÇ int Istat, (const char * path, struct stat *_buf) J3 

01776 


01777 #endif /* _STAT_H */ 


DO one Do O O A O +EH HHHH +H H+H HHHH HHHH HHH HHHH HHHH HHHH HHHH H+H +H O DO O OD O DR 
include/sys/dir.h 
DO sn Do o O A O O H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH H+H HHHH HHH DO OO O O O DO 


01800 /* O cabeçalho <dir.h> fornece o layout de um diretório. */ 
01801 

01802 &ifndef DIR H 

01803 &define DIR H 


01804 

01805 #include <sys/types.h> 

01806 

01807 #define DIRBLKSIZ 512 /* tamanho do bloco do diretório */ 
01808 


01809 #ifndef DIRSIZ 

01810 #define DIRSIZ 60 
01811 #endif 

01812 

01813 struct direct { 

01814 ino_t d_ino; 

01815 char d_name[DIRSIZ]; 
01816 }; 

01817 

01818 #endif /* _DIR_H */ 


DO one Do O o O O O HHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ O O O O OO OD O O DO 
include/sys/wait.h 
DO spa oo o o O O O HHHH HHHH HHHH HHH H+H HHHH HH HHHH HHHH HHHH HHH O O DO OO OO O 


01900 /* O cabeçalho <sys/wait.h> contém macros relacionadas com wait). O valor 


01901 * retornado por wait() e waitpid() depende se o processo foi 
01902 * terminado por uma chamada de exit()D, eliminado por um sinal ou parado 
01903 * devido ao controle de tarefas, como segue: 


01904 * 
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01905 
01906 
01907 
01908 
01909 
01910 
01911 
01912 
01913 
01914 
01915 
01916 
01917 
01918 
01919 
01920 
01921 
01922 
01923 
01924 
01925 
01926 
01927 
01928 
01929 
01930 
01931 
01932 
01933 
01934 
01935 
01936 
01937 
01938 
01939 


Byte alto Byte baixo 


+--------------------- + 
+ saída(status) | status | 0 | 
* +--------------------- + 
x eliminado pelo sinal | 0 | sinal | 
K +--------------------- $ 
$ parado (controle de tarefas) | sinal | 0177 
$ +--------------------- + 
* / 
iifndef WAIT H 
gdefine WAIT H 
tifndef |. TYPES H 
tinclude <sys/types.h> 
#endif 
#define _LOW(Cv) C Cv) & 0377) 
#define _HIGH(v) C CCv) >> 8) & 0377) 
#define WNOHANG 1 /* não espera o filho sair */ 
tdefine WUNTRACED 2 /* para controle de tarefas; não implementado */ 
gdefine WIFEXITED(s) (LOW(s) == 0) /* saída normal */ 
#define WEXITSTATUS(s) (C HIGH(s)) /* status de saída */ 
#define WTERMSIG(s) CLOW(s) & 0177) /* valor do sinal */ 
#define WIFSIGNALED(s)  ((Cunsigned int)(s)-1 & OxFFFF) < OxFF) /* sinalizado */ 
tdefine WIFSTOPPED(s) CLOW(s) == 0177) /* parado */ 
tdefine WSTOPSIG(s) CHIGH(s) & 0377) /* sinal de parada */ 


/* Prototypes de Função. */ 
- PROTOTYPE( pid t wait, (int * stat Toc) ys 
_PROTOTYPE(Ç pid_t waitpid, (pid_t _pid, int *_stat_loc, int options) ) 


#endif /* _WAIT_H */ 


HHHEHHHHH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


include/sys/ioctl.h 


HEHEHEHEH HHHH HHHH HHH HH HH H+ HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH HHHH HH+H+H+H+H+H+H+H+H+ 


02000 
02001 
02002 
02003 
02004 
02005 
02006 
02007 
02008 
02009 
02010 
02011 
02012 
02013 
02014 
02015 
02016 
02017 
02018 
02019 


/* sys/ioctl.h - Todos os códigos de comando octl(). Autor: Kees J. Bot 
¥ 23 de nov de 2002 
* Este arquivo de cabeçalho inclui todos os outros cabeçalhos de código de comando ioctl. 


*/ 


#ifndef _S_IOCTL_H 
#define _S_IOCTL_H 


/* Um driver que usa ioctl reivindica um caractere para sua série de comandos. 
* Por exemplo: #define TCGETS IOR(C'T', 8, struct termios) 
* Esse é um ioctl de terminal que usa o caractere 'T”. O(s) caractere(s) 


* usado(s) em cada arquivo de cabeçalho são mostrados no comentário a seguir. 


*/ 


#include <sys/ioc tty.h> JET pre */ 
tinclude <sys/ioc disk.h> /* "dd? * 
tinclude <sys/ioc memory.h> VÁ 
tinclude <sys/ioc cmos.h> 7: 
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02020 


gendif /* S IOCTL H */ 


HEHEHEHEH HEHH HHHH HHH HH H+H H+ HH HH H+H H+H HH HHHH HHHH H+H HHHH H+ HHE H+H+HH+HH+H+H+H+H+H+H+H+H+ 


include/sys/ioc_disk.h 


HEHEHEHEH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH HH HHH H+H HHHH HHHH HHHH H+H+HH+H+H+H+H+H+ 


02100 
02101 
02102 
02103 
02104 
02105 
02106 
02107 
02108 
02109 
02110 
02111 
02112 
02113 
02114 
02115 
02116 


/* sys/ioc disk.h -- Códigos de comando ioctl() de disco. Autor: Kees J. Bot 
* 23 de nov de 2002 


*/ 


#ifndef _S_I_DISK_H 
#define SI DISKH 


tinclude <minix/ioctl.h> 


tdefine DIOCSETP _IOWÇ’d’, 3, struct partition) 
tdefine DIOCGETP “IORC'd”, 4, struct partition) 
tdefine DIOCEJECT BO ('0",-5) 

tdefine DIOCTIMEOUT _IOWÇ’d’, 6, int) 

tdefine DIOCOPENCT “IORC'd”, 7, int) 


gendif /* SI DISKH */ 


HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HHH HH HHHH H+H HH HHHH H+H HHHH HHHH HHHH HH+H+HH+H+H+H+H+H+ 


include/minix/ioctl.h 


HHHHHHHHH HHHH HHHH H+H HHHH HH HH HH HHH H+H HHHH HHHH ++ 


02200 
02201 
02202 
02203 
02204 
02205 
02206 
02207 
02208 
02209 
02210 
02211 
02212 
02213 
02214 
02215 
02216 
02217 
02218 
02219 
02220 
02221 
02222 
02223 
02224 


/* minix/ioctl.h - Definições auxiliares de ioctl. Autor: Kees J. Bot 
$ 23 de nov de 2002 


is 


tifndef M IOCTL H 
tdefine M IOCTL H 


tifndef |. TYPES H 
tinclude <sys/types.h> 
Hendif 


Hif EM WSIZE >= 4 
/* Os ioctls têm o comando codificado na palavra de ordem inferior e o tamanho 
* do parâmetro na palavra de ordem superior. Os 3 bits superiores da palavra 
* de ordem superior são usados para codificar o status in/out/void do parâmetro. 


*/ 
tdefine | IOCPARM MASK 0x1FFF 
#define | IOC VOID 0x20000000 
tdefine - IOCTYPE MASK OxFFFF 
#define  IOC IN 0x40000000 
#define | IOC OUT 0x80000000 
#define | IOC INOUT CIOC IN | _IOC_OUT) 


* Este arquivo é incluído por todo arquivo de cabeçalho que define códigos ioctl. 
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02225 #define IO(x,y) C(x << 8) | y | -IOC VOID) 

02226 #define IOR(x,y,t) C(x << 8) | y | CCsizeof(t) & | IOCPARM MASK) << 16) IN 
02227 -IOC OUT) 

02228 #define IOW(x,y,t) C(x << 8) | y | CCsizeof(t) & | IOCPARM MASK) << 16) IN 
02229 _IOC_IN) 

02230 #define _IORW(x,y,t)  ((x << 8) | y | ((sizeof(t) & _IOCPARM_MASK) << 16) IN 
02231 _IOC_INOUT) 


02232 else 
02233 /* Não é uma codificação elegante em uma máquina de 16 bits. */ 


02234 

02235 define IO(x,y) (x << 8) | y) 
02236 #define _IOR(x,y,t) _I0O(x,y) 
02237 #define _IOW(x,y,t) _I0O(x,y) 


02238 #define _IORW(x,y,t)  _IO(x,y) 

02239 #endif 

02240 

02241 int ioctl(int fd, int request, void * data); 
02242 

02243 &endif /* M IOCTL H */ 


DO spa Do O O a O +H HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O DO O OO O O 
include/minix/config.h 
HHHEHEHHHHHHH + HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH H+H O O O DO OO O O O O 


02300 #ifndef _CONFIG_H 

02301 #define _CONFIG_H 

02302 

02303 /* Números de lançamento e versão do Minix. */ 
02304 #define OS RELEASE "3" 

02305 #define OS VERSION "1.0" 


02306 

02307 /* Este arquivo define os parâmetros de configuração do núcleo do MINIX, FS e PM. 
02308 * Ele está dividido em duas seções principais. A primeira seção contém 

02309 * parâmetros configurados pelo usuário. Na segunda seção, vários parâmetros 

02310 * internos do sistema são configurados com base nos parâmetros configurados pelo usuário. 
02311 $ 

02312 * Partes de config.h foram movidas para sys_config.h, que pode ser incluído 

02313 * por outros arquivos include que queiram obter os dados de configuração, mas 

02314 * não querem poluir o espaço de nome dos usuários. Alguns valores que podem ser 
02315 * editados foram para lá. 

02316 £ 

02317 * Esta é uma versão modificada de config.h para compilar um sistema Minix pequeno 
02318 * apenas com as opções descritas no texto deste livro. 

02319 * Veja a versão de config.h no diretório 

02320 * de código-fonte completo para obter informações sobre alternativas omitidas aqui. 
02321 x 

02322 


02323 /* A configuração de MACHINE (chamada _MINIX_MACHINE) pode ser feita 
02324 * em <minix/machine.h>. 


02325 */ 

02326 #include <minix/sys_config.h> 

02327 

02328 #define MACHINE - MINIX MACHINE 
02329 

02330 &define IBM PC - MACHINE IBM PC 
02331 ádefine SUN 4 - MACHINE SUN 4 
02332 #define SUN 4 60 MACHINE SUN 4 60 
02333 #define ATARI - MACHINE ATARI 


02334 #define MACINTOSH _MACHINE_MACINTOSH 
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02335 
02336 
02337 
02338 


02339 
02340 
02341 
02342 
02343 
02344 
02345 
02346 
02347 
02348 
02349 
02350 
02351 
02352 
02353 
02354 
02355 
02356 
02357 
02358 
02359 
02360 
02361 
02362 
02363 
02364 
02365 
02366 
02367 
02368 
02369 
02370 
02371 
02372 
02373 
02374 
02375 
02376 
02377 
02378 
02379 
02380 
02381 
02382 
02383 
02384 
02385 
02386 


02387 
02388 
02389 
02390 
02391 


02392 
02393 
02394 


/* Número de entradas na tabela de processos para processos que não são do núcleo. 
* O número de processos de sistema define quantos processos com privilégios especiais 
* podem existir. Os processos de usuário compartilham as mesmas propriedades e contam como 
um. 


* Isso pode ser alterado em sys config.h. 


A 
define NR PROCS -NR PROCS 
define NR SYS PROCS -NR SYS PROCS 


gdefine NR BUFS 128 
tdefine NR BUF HASH 128 


/* Número de tarefas da controladora (classes de dispositivo /dev/cN). */ 
tdefine NR CTRLRS 2 


/* Ativa ou desativa a cache de sistema de arquivos de segundo nível no disco de RAM. */ 
tdefine ENABLE CACHEZ 0 


/* Ativa ou desativa a troca de processos no disco. */ 
tdefine ENABLE SWAP 0 


/* Inclui ou exclui uma imagem de /dev/boot na imagem de inicialização. 
* Atualize também o arquivo make em /usr/src/tools/. 
*/ 
tdefine ENABLE BOOTDEV 0 /* carrega a imagem de /dev/boot na inicialização */ 


/* DMA SECTORS pode ser aumentado para acelerar drivers baseados em DMA. */ 
tdefine DMA SECTORS 1 /* tamanho do buffer de DMA (deve ser >= 1) */ 


/* Inclui ou exclui código de compatibilidade com versões anteriores. */ 
#define ENABLE BINCOMPAT O /* para binários usando chamadas obsoletas */ 
#define ENABLE SRCCOMPAT 0 /* para códigos-fonte usando chamadas obsoletas */ 


/* Qual processo deve receber diagnóstico do núcleo e do sistema? 
* Enviá-lo diretamente para TTY só exibe a saída. Enviá-lo para o 
* driver de log fará o diagnóstico ser colocado no buffer e exibido. 
*/ 
#define OUTPUT_PROC_NR LOG_PROC_NR /* TTY_PROC_NR or LOG_PROC_NR */ 


/* NR CONS, NR RS LINES e NR PTYS determinam o número de terminais que o 
* sistema consegue manipular. 


tdefine NR CONS 4 /* & consoles de sistema (de 1 a 8) */ 
tdefine NR RS LINES 0 /* & terminais rs232 (de 0 a 4) */ 
tdefine NR PTYS 0 /* & pseudo-terminais (de O a 64) */ 


/* Configura o tipo de CHIP com base na máquina selecionada. O símbolo CHIP é, na verdade, 
uma indicação de mais do que apenas a CPU. Por exemplo, espera-se que as máquinas para as 
quais 

* CHIP == INTEL tenham controladoras de interrrupção 8259A e as 

* outras propriedades de máquinas tipo IBM PC/XT/AT/386 em geral. */ 


tdefine INTEL - CHIP INTEL /* tipo de CHIP para PC, XT, AT, 386 e clones */ 
tdefine M68000 - CHIP M68000 /* tipo de CHIP para Atari, Amiga, Macintosh */ 
tdefine SPARC - CHIP SPARC /* tipo de CHIP para SUN-4 (por exemplo, 


SPARCstation) */ 


/* Configura o tipo de FP FORMAT com base na máquina selecionada, ou hw ou sw */ 
ádefine FP NONE FP NONE /* nenhum suporte para ponto flutuante */ 
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02395 
02396 
02397 
02398 
02399 
02400 
02401 
02402 
02403 
02404 
02405 
02406 
02407 


gdefine FP IEEE FP TEEE /* obedece o padrão de ponto flutuante IEEE */ 


/* MINIX CHIP é definido em sys config.h. */ 
tdefine CHIP “MINIX CHIP 


/* MINIX FP FORMAT é definido em sys config.h. */ 
tdefine FP FORMAT -MINIX FP FORMAT 


/* _ASKDEV e FASTLOAD são definidos em sys config.h. */ 
ádefine ASKDEV  ASKDEV 
ádefine FASTLOAD _FASTLOAD 


#endif /* CONFIG H */ 


HHHHHHHHH HHHH HHHH HHHH H+H HHH HH HHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH HHHH HHHH 


include/minix/sys_config.h 
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02500 
02501 
02502 
02503 
02504 
02505 
02506 
02507 
02508 
02509 
02510 
02511 
02512 
02513 
02514 
02515 
02516 
02517 
02518 
02519 
02520 
02521 
02522 
02523 
02524 
02525 
02526 
02527 
02528 
02529 
02530 
02531 
02532 
02533 
02534 
02535 
02536 
02537 
02538 
02539 


#ifndef _MINIX_SYS_CONFIG_H 
#define _MINIX_SYS_CONFIG_H 1 


/* Este é um arquivo sys_config.h modificado para compilar um sistema Minix pequeno 
* apenas com as opções descritas no texto deste livro. 
* Veja o arquivo sys_config.h no diretório 
* de código-fonte completo para obter informações sobre as alternativas omitidas aqui. 


7 


define  MINIX MACHINE MACHINE IBM PC 


tdefine MACHINE IBM PC 1 /* qualquer sistema baseado no 8088 no 80x86 */ 


/* Tamanho de palavra em bytes (uma constante igual a sizeof(int)). */ 
#if __ ACK, || GNUC 


tdefine WORD SIZE - EM WSIZE 
tdefine PTR SIZE - EM WSIZE 
#endif 

#define _NR_PROCS 64 


#define _NR_SYS_PROCS 32 


/* Configura o tipo de CHIP com base na máquina selecionada. O símbolo CHIP é, na verdade, 
* uma indicação de mais do que apenas a CPU. Por exemplo, espera-se que máquinas 


* para as quais CHIP == INTEL tenham controladoras de interrrupção 8259A e as 

* outras propriedades das máquinas tipo IBM PC/XT/AT/386 em geral. */ 
#define _CHIP_INTEL T /* tipo de CHIP para PC, XT, AT, 386 e clones */ 
/* Configura o tipo de FP FORMAT com base na máquina selecionada, ou hw ou sw */ 
tdefine FP NONE 0 /* nenhum suporte para ponto flutuante */ 
#define FP IEEE T /* obedece o padrão de ponto flutuante IEEE */ 
#define _MINIX_CHIP _CHIP_INTEL 


#define _MINIX_FP_FORMAT _FP_NONE 


#ifndef _MINIX_MACHINE 
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02540 error "In <minix/sys config.h> please define | MINIX MACHINE” 
02541 #endif 

02542 

02543 &ifndef MINIX CHIP 

02544 error "In <minix/sys config.h> please define MINIX MACHINE to have a legal value” 
02545 #endif 

02546 

02547 #if C(MINIX MACHINE == 0) 

02548 error " MINIX MACHINE has incorrect value (0)" 

02549 #endif 

02550 

02551 #endif /* MINIX SYS CONFIG H */ 

02552 

02553 


DO spa oo O O O O DO HHHH HHHH HHHH HHHH HHHH HH HHHH H+ HH HHHH O O O O DO O O O RO 
include/minix/const.h 
HHHEHEHHHHHHH HHHH H+H HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ O O DD OO OD O O 


02600 /* Copyright (C) 2001 by Prentice-Hall, Inc. Veja o aviso de copyright no 
02601 * arquivo /usr/src/LICENSE. 

02602 */ 

02603 

02604 #ifndef CHIP 

02605 #error CHIP is not defined 

02606 #endif 


02607 

02608 #define EXTERN extern /* usado em arquivos *.h */ 

02609 #define PRIVATE static /* PRIVATE x limita o escopo de x */ 

02610 #define PUBLIC /* PUBLIC é o oposto de PRIVATE */ 

02611 #define FORWARD static /* alguns compiladores exigem que isso seja 'static'*/ 
02612 

02613 define TRUE 1 /* usado para transformar valores inteiros em booleanos */ 
02614 define FALSE 0 /* usado para transformar valores inteiros em booleanos */ 
02615 

02616 define HZ 60 /* freq. do relógio (configurável por software) */ 

02617 

02618 define SUPER USER (uid t) O /* uid t do superusuário */ 

02619 

02620 /* Dispositivos. */ 

02621 define MAJOR 8 /* dispositivo principal = (dev>>MAJOR) & 0377 */ 

02622 define MINOR 0 /* dispositivo secundário = (dev>>MINOR) & 0377 */ 

02623 

02624 define NULL (Cvoid *)0) /* ponteiro nulo */ 

02625 define CPVEC NR 16 /* número máx de entradas em uma requisição de SYS VCOPY */ 
02626 define CPVVEC NR 64 /* número máx de entradas em uma requisição de SYS VCOPY */ 
02627 ádefine NR IOREQS MINCNR BUFS, 64) 

02628 /* número máximo de entradas em um iorequest */ 

02629 

02630 /* Constantes para passagem de mensagem. */ 

02631 #define MESS SIZE (sizeof(message)) /* talvez precise de usizeof do DS aqui */ 

02632 ádefine NIL MESS ((message *) 0) /* ponteiro nulo */ 

02633 

02634 /* Constantes relacionadas à memória. */ 

02635 define SEGMENT TYPEOxFFOO /* máscara de bits para obter tipo do segmento */ 


02636 gdefine SEGMENT INDEX 0x00FF /* máscara de bits para obter índice do segmento */ 
02637 

02638 gdefine LOCAL SEG 0x0000 /* flags indicando segmento de memória local */ 
02639 define NR LOCAL SEGS 3 /* número de segmentos locais por processo (fixo) */ 
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02640 #define T 0 /* proc[i].mem map[T] é para texto */ 

02641 define D 1 /* proc[i].mem map[D] é para dados */ 

02642 #define S 2 /* proc[i].mem_map[S] é para pilha */ 

02643 

02644 #define REMOTE SEG 0x0100 /* flags indicando segmento de memória remoto */ 
02645 define NR REMOTE SEGS 3 /* & regiões de memória remotas (variável) */ 
02646 

02647 define BIOS SEG 0x0200 /* flags indicando segmento de memória da BIOS */ 
02648 define NR BIOS SEGS 3 /* número de regiões de memória da BIOS (variável) */ 
02649 

02650 #define PHYS SEG 0x0400 /* flag indicando a memória física inteira */ 
02651 


02652 /* Rótulos usados para desativar seções de código por diferentes motivos. */ 


02653 gdefine DEAD CODE 0 /* código não utilizado na configuração normal */ 

02654 #define FUTURE CODE 0 /* código novo a ser ativado e testado posteriormente */ 
02655 #define TEMP CODE 1 /* código ativo a ser removido posteriormente */ 

02656 


02657 /* Comprimento de nome de processo na tabela de processos do PM, incluindo "NO". */ 
02658 define PROC NAME LEN 16 


02659 

02660 /* Miscelânea */ 

02661 define BYTE 0377 /* máscara para 8 bits */ 

02662 define READING 0 /* copia dados para o usuário */ 

02663 define WRITING 1 /* copia dados do usuário */ 

02664 #define NO NUM 0x8000 /* usado como argumento numérico para panic) */ 
02665 #define NIL PTR (char *) 0 /* expressão geralmente útil */ 


02666 define HAVE SCATTERED I01 /* E/S dispersa agora é padrão */ 
02667 

02668 /* Macros. */ 

02669 define MAX(a, b) (Ca) > Cb) ? (a) = Cb)) 

02670 #define MIN(a, b) (Ca) < (b) ? (a) : (b)) 

02671 

02672 /* A memória é alocada em clicks. */ 

02673 #if (CHIP == INTEL) 


02674 #define CLICK SIZE 1024 /* unidade na qual a memória é alocada */ 
02675 #define CLICK SHIFT 10 /* log2 de CLICK SIZE */ 

02676 #endif 

02677 

02678 #if (CHIP == SPARC) || (CHIP == M68000) 

02679 #define CLICK SIZE 4096 /* unidade na qual a memória é alocada */ 
02680 ádefine CLICK SHIFT 12 /* log2 de CLICK SIZE */ 

02681 #endif 

02682 

02683 /* Conversões de click para byte (e vice-versa). */ 

02684 define HCLICK SHIFT 4 /* log2 de HCLICK SIZE */ 

02685 define HCLICK SIZE 16 /* mágica da conversão de segmento de hardware */ 


02686 #if CLICK SIZE >= HCLICK SIZE 

02687 #define click to hclick(n) ((n) << (CLICK SHIFT - HCLICK SHIFT)) 
02688 #else 

02689 &define click to hclick(n) ((n) >> (HCLICK SHIFT - CLICK SHIFT)) 
02690 #endif 

02691 #define hclick to physb(n) (Cphys bytes) (n) << HCLICK SHIFT) 
02692 #define physb to hclick(n) (Cn) >> HCLICK SHIFT) 


02693 

02694 gdefine ABS -999 /* este processo significa memória absoluta */ 
02695 

02696 /* Bits de flag para i mode no i-node. */ 

02697 gdefine I TYPE 0170000 /* este campo fornece o tipo de i-node */ 

02698 gdefine I REGULAR 0100000 /* arquivo regular, não diretório nem especial */ 


02699 gdefine I BLOCK SPECIAL 0060000 /* arquivo especial de bloco */ 
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02700 
02701 
02702 
02703 
02704 
02705 
02706 
02707 
02708 
02709 
02710 
02711 
02712 
02713 
02714 
02715 
02716 
02717 
02718 
02719 
02720 
02721 
02722 
02723 
02724 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


/* Flag 
tdefine 


/* Algu 
tdefine 
tdefine 
tdefine 
tdefine 


tdefine 
tdefine 
tdefine 
tdefine 


I DIRECTORY 0040000 /* o arquivo é um diretório */ 

I CHAR SPECIAL 0020000 /* arquivo de caractere especial */ 

I NAMED PIPE 0010000 /* pipe nomeado (FIFO) */ 

I SET UID BIT 0004000 /* configura uid t efetiva na execução */ 


I SET GID BIT 0002000 /* configura gid t efetiva na execução */ 

ALL MODES 0006777 /* todos os bits para usuário, grupo e outros */ 

RWX MODES 0000777 /* bits de modo somente para RWX */ 

R BIT 0000004 /* bit de proteção Rwx */ 

Ww BIT 0000002 /* bit de proteção rwx */ 

X BIT 0000001 /* bit de proteção rwX */ 

I NOT ALLOC 0000000 /* este i-node está livre */ 

usado apenas em argumento de flags de dev open. */ 

RO BIT 0200000 /* Abre disp. somente p/ leitura: erro se gravável */ 

ns limites. */ 

MAX BLOCK NR ((block t) 077777777) /* maior número de bloco */ 

HIGHEST ZONE ((zone t) 077777777) /* maior número de zona */ 

MAX INODE NR ((ino t) 037777777777) /* maior número de i-node */ 

MAX FILE POS ((Coff t) 037777777777) /* maior deslocamento de arquivo válido */ 
NO BLOCK (Cblock t) 0) /* ausência de um número de bloco */ 

NO ENTRY (Cino t) 0) /* ausência de uma entrada de diretório */ 
NO ZONE ((zone t) 0) /* ausência de um número de zona */ 

NO DEV (C(dev t) 0) /* ausência de um número de dispositivo */ 


HHHEHEHHHH+HH H+ HHHH HHHH HH HH HHH HHH HH HHHH HHH HH HHHH H+H HHHH H+ HHH H+HHH+HH+H+HH+H+H+H+H+H+ 


include/minix/type.h 


HHHHHHHHH HHHH HHHH HHHH HH HH HH HHHH H+H HHHH HHHH ++ 


02800 
02801 
02802 
02803 
02804 
02805 
02806 
02807 
02808 
02809 
02810 
02811 
02812 
02813 
02814 
02815 
02816 
02817 
02818 
02819 
02820 
02821 
02822 
02823 
02824 
02825 
02826 
02827 
02828 
02829 


#ifndef _TYPE_H 


#define 


—IYPE H 


#ifndef | MINIX SYS CONFIG H 
ginclude <minix/sys config.h> 


Hendif 

tifndef |. TYPES H 

ginclude <sys/types.h> 

Hendif 

/* Definições de tipo. */ 

typedef unsigned int vir clicks; /* endereço/comprimento virtual em clicks */ 
typedef unsigned Tong phys bytes; /* endereço/comprimento físico em bytes */ 
typedef unsigned int phys clicks; /* endereço/comprimento físico em clicks */ 
#if CMINIX CHIP == CHIP INTEL) 

typedef unsigned int vir bytes; /* endereços e comprimentos virtuais em bytes */ 
Hendif 

#if CMINIX CHIP == CHIP M68000) 

typedef unsigned long vir bytes;/* endereços e comprimentos virtuais em bytes */ 
Hendif 

#if C(MINIX CHIP == CHIP SPARC) 

typedef unsigned Tong vir bytes;/* endereços e comprimentos virtuais em bytes */ 
Hendif 


/* Mapa de memória para texto local, pilha, segmentos de dados. */ 


struct 


mem map 1 
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02830 vir clicks mem vir; /* endereço virtual */ 
02831 phys clicks mem phys; /* endereço físico */ 
02832 vir clicks mem Ten; /* comprimento */ 
02833 F}; 

02834 


02835 /* Mapa de memória para áreas de memória remotas, por exemplo, para o disco de RAM. */ 
02836 struct far mem { 


02837 int in use; /* entrada em uso, a menos que seja zero */ 
02838 phys clicks mem phys; /* endereço físico */ 

02839 vir clicks mem Ten; /* comprimento */ 

02840 3; 

02841 


02842 /* Estrutura para cópia virtual por meio de um vetor com requisições. */ 
02843 struct vir addr { 
02844 int proc nr; 


02845 int segment; 
02846 vir bytes offset; 
02847 5; 

02848 


02849 #define phys cp reg vir cp req 
02850 struct vir cp req 1 


02851 struct vir addr src; 

02852 struct vir addr dst; 

02853 phys bytes count; 

02854 5; 

02855 

02856 typedef struct { 

02857 vir_bytes iov_addr; /* endereço de um buffer de E/S */ 

02858 vir_bytes iov_size; /* tamanho de um buffer de E/S */ 

02859 } iovec_t; 

02860 

02861 /* O PM passa o endereço de uma estrutura desse tipo para o KERNEL quando 
02862 * sys sendsig() é chamada como parte do mecanismo de captura de sinal. 

02863 * A estrutura contém todas as informações que o KERNEL precisa para construir 
02864 * a pilha de sinais. 

02865 vá 

02866 struct sigmsg 1 

02867 int sm signo; * número do sinal que está sendo capturado */ 


/ 
02868 unsigned long sm mask; /* máscara a restaurar no retorno da rot. tratamento */ 
02869 vir bytes sm sighandler; /* endereço da rotina de tratamento */ 
/ 
/ 


02870 vir bytes sm sigreturn; * endereço de sigreturn na biblioteca C */ 
02871 vir bytes sm stkptr; * ponteiro da pilha de usuário */ 

02872 3; 

02873 


02874 /* Isto é usado para obter informações do sistema por meio de SYS GETINFO. */ 
02875 struct kinfo 1 


02876 phys bytes code base; /* base de código do núcleo */ 

02877 phys bytes code size; 

02878 phys bytes data base; /* base de dados do núcleo */ 

02879 phys bytes data size; 

02880 vir bytes proc addr; /* endereço virtual da tabela de processos */ 

02881 phys bytes kmem base; /* layout da memória do núcleo (/dev/kmem) */ 

02882 phys bytes kmem size; 

02883 phys bytes bootdev base; /* dispositivo de inicialização da imagem (/dev/boot) */ 


02884 phys bytes bootdev size; 
02885 phys bytes bootdev mem; 


02886 phys bytes params base; /* parâmetros passados pelo monitor de inicialização */ 
02887 phys bytes params size; 
02888 int nr procs; /* número de processos de usuário */ 


02889 int nr tasks; /* número de tarefas do núcleo */ 
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02890 
02891 
02892 
02893 
02894 
02895 
02896 
02897 
02898 
02899 
02900 
02901 
02902 
02903 
02904 


char release[6]; 
char version[6]; 
int relocking; 


3; 


struct machine { 
int pc_at; 
int ps_mca; 
int processor; 
int protected; 
int vdu_ega; 
int vdu_vga; 


Js 


#endif /* _TYPE_H */ 


/* número de lançamento do núcleo */ 
/* número da versão do núcleo */ 
/* verificação de novo travamento (para depuração) */ 


HEHEHEHEH HHHH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH H+H HHH H+H HHHH HHHH H+ HHH H+H+H+H+H+H+H+H+H+ 


include/minix/ipc.h 


HEHEHEHEH HHHH HHHH HHH HH H+H HH HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH HHHH HH+H+H+H+H+H+H+H+H+ 


03000 
03001 
03002 
03003 
03004 
03005 
03006 
03007 
03008 
03009 
03010 
03011 
03012 
03013 
03014 
03015 
03016 
03017 
03018 
03019 
03020 
03021 
03022 
03023 
03024 
03025 
03026 
03027 
03028 
03029 
03030 
03031 
03032 
03033 
03034 
03035 
03036 
03037 
03038 
03039 


#ifndef _IPC_H 
#define _IPC_H 
/¥======== Y 


#define 
#define 
#define 
#define 


typedef 
typedef 
typedef 
typedef 
typedef 
typedef 
typedef 


typedef 


int mo 
int mo 


union 


} mu; 


M3_STRING 


struct {int m1il, m1i2, m1i3; char *m1p1, *mlp2, *mlp3;) mess 1; 

struct {int m2il, m2i2, m2i3; long m211, m212; char *m2p1;} mess 2; 
struct {int m3il, m3i2; char *m3p1; char m3ca1[M3_STRING];} mess 3; 
struct {long m411, m412, m413, m414, m415;3 mess 4; 

struct {short m5cl, m5c2; int m5il, m5i2; long m511, m512, m513;Jmess 5; 
struct {int m7il, m7i2, m7i3, m7i4; char *m7p1l, *m7p2;) mess 7; 

struct {int m8il, m8i2; char *m8p1, *m8p2, *m8p3, *m8p4;) mess 8; 


struct 1 
source; 
type; 

{ 


mess_1 mml; 
mess_2 m_m2?; 
mess_3 m m3; 
mess_4 m m4; 
mess_5 m_m5; 
mess_7 m_m7; 
mess_8 m m8; 


} message; 


/* As definições a 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


mLil mu. 
mLi2Z2 mu. 
ml1_i3 mu. 
mi pi mu. 
mi p2 mu. 


/* quem enviou a mensagem */ 
/* qual é o tipo de mensagem */ 


seguir fornecem nomes de membros úteis. */ 


mml. 
m ml. 
m ml. 
mml. 
mml. 


mlil 
mli2 
mli3 
mipl 
mip2 
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03040 #define ml p3 m u.m m1.m1p3 
03041 

03042 &definem2 il m_ u.m m2.m2il 
03043 &define m2 i2 m_u.m m2.m2i2 
03044 definem? i3 mu.m m2.m2i3 
03045 &definem2 11 m_ u.m m2.m211 
03046 &definem2 12 mu.m m2.m212 
03047 #define m2 pl mu.m m2.m2pl 
03048 

03049 &definem3 il mu.mm3.m3il 
03050 &define m3 i2 mu.mm3.m3i2 
03051 ádefine m3 pl mu.m m3.m3pl 
03052 &define m3 cal mu.m m3.m3cal 
03053 

03054 &definem4 11 m_ u.m m4.m411 
03055 &definem4 12 mu.m m4.m412 
03056 &definem4 13 mu.m m4.m413 
03057 &definem4 14 mu.m m4.m414 
03058 &definem4 15 mu.m m4.m415 
03059 

03060 &definem5 ci m_ u.m m5.m5c1 
03061 &define m5 c2 mu.m m5.m5c2 
03062 &define m5 il m_ u.m m5.m5i1 
03063 &define m5_i2 mu.mm5.m5i2 
03064 &definem5 11 m_ u.m m5.m511 
03065 &define m5 12 mu.mm5.m512 
03066 ádefine m5 13 mu.m m5.m513 
03067 

03068 &definem7 il mu.mm7.m7il 
03069 &definem7 i2 mu.mm7.m7i2 
03070 &definem7 i3 mu.mm7.m7i3 
03071 &definem7 i4 mu.mm7.m7i4 
03072 4definem7 pl mu.mm7.m7p1 
03073 #define m7 p2 m u.mm7.m7p2 
03074 

03075 &define m8 il mu.m m8.m8il 
03076 &define m8 i2 mu.m m8.m8i2 
03077 #define m8 pl m u.m m8.m8p1 
03078 #define m8 p2 m u.m m8.m8p2 
03079 #define m8 p3 m u.m m8.m8p3 
03080 #define m8 p4 m u.m m8.m8p4 


03081 

03082 

03083 * 
03084 * ===> / 
03085 

03086 /* Oculta nomes para evitar poluição do espaço de nomes. */ 

03087 #define echo “echo 

03088 ádefine notify “notify 

03089 define sendrec _sendrec 

03090 #define receive _receive 

03091 #define send _send 

03092 #define nb_receive “nb receive 

03093 &define nb send “nb send 

03094 


03095 | PROTOTYPE( int echo, (message *m ptr) 

03096 | PROTOTYPE( int notify, (int dest) 

03097 | PROTOTYPE( int sendrec, (int src dest, message *m ptr) 
03098 | PROTOTYPE( int receive, (int src, message *m ptr) 
03099 | PROTOTYPE( int send, (int dest, message *m ptr) 


NO NO NO NO O 
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03100 
03101 
03102 
03103 


- PROTOTYPE( int nb receive, (int src, message *m ptr) js 
- PROTOTYPE( int nb send, (int dest, message *m ptr) js 


#endif /* _IPC_H */ 


HEHEHEHEH HEHH HHHH HHH HH H+H H+ HH HHH HH HHH HH HHHH HHHH H+H HHHH HHHH HHHH HH+H+HH+H+H+H+H+H+ 


include/minix/syslib.h 
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03200 
03201 
03202 
03203 
03204 
03205 
03206 
03207 
03208 
03209 
03210 
03211 
03212 
03213 
03214 
03215 
03216 
03217 
03218 
03219 
03220 
03221 
03222 
03223 
03224 
03225 
03226 
03227 
03228 
03229 
03230 
03231 
03232 
03233 
03234 
03235 
03236 
03237 
03238 
03239 
03240 
03241 
03242 
03243 
03244 
03245 
03246 
03247 
03248 
03249 


/* Prototypes para funções de biblioteca do sistema. */ 


tifndef - SYSLIB H 
tdefine _SYSLIB_H 


gifndef |. TYPES H 
tinclude <sys/types.h> 
Hendif 


tifndef _IPC_H 
tinclude <minix/ipc.h> 
#endif 


#ifndef _DEVIO_H 
#include <minix/devio.h> 
#endif 


/* Declaração antecipada */ 
struct reg86u; 


define SYSTASK SYSTEM 


* Biblioteca de sistema do Minix. 
p e A e a a a E a / 
- PROTOTYPE( int _taskcall, (int who, int syscallnr, message *msgptr)); 


- PROTOTYPE( int sys_abort, (int how, ...)); 
- PROTOTYPE( int sys exec, (int proc, char *ptr, 
char *aout, vir bytes initpo)); 
- PROTOTYPE( int sys fork, (int parent, int child); 
- PROTOTYPEC int sys newmap, (int proc, struct mem map *ptr)); 
- PROTOTYPE( int sys exit, (int proc)); 
- PROTOTYPE( int sys trace, (int reg, int proc, long addr, Tong *data p)); 


- PROTOTYPE( int sys svrctl, (int proc, int reg, int priv,vir bytes argp)); 
- PROTOTYPE( int sys nice, (int proc, int priority)); 


- PROTOTYPE( int sys int86, (struct reg86u *reg86p)); 


/* Atalhos para a chamada de sistema sys sdevioQO). */ 
tdefine sys insb(port, proc nr, buffer, count) A 

sys sdevio(DIO INPUT, port, DIO BYTE, proc nr, buffer, count) 
tdefine sys insw(port, proc nr, buffer, count) À 

sys sdevio(DIO INPUT, port, DIO WORD, proc nr, buffer, count) 
tdefine sys outsb(port, proc nr, buffer, count) \ 

sys sdevio(DIO OUTPUT, port, DIO BYTE, proc nr, buffer, count) 
#define sys outsw(port, proc nr, buffer, count) N 

sys sdevio(DIO OUTPUT, port, DIO WORD, proc nr, buffer, count) 
- PROTOTYPE( int sys sdevio, (int req, long port, int type, int proc nr, 
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03250 
03251 
03252 
03253 
03254 
03255 
03256 
03257 
03258 
03259 
03260 
03261 
03262 
03263 
03264 
03265 
03266 
03267 
03268 
03269 
03270 
03271 
03272 
03273 
03274 
03275 
03276 
03277 
03278 
03279 
03280 
03281 
03282 
03283 
03284 
03285 
03286 
03287 
03288 
03289 
03290 
03291 
03292 
03293 
03294 
03295 
03296 
03297 
03298 
03299 
03300 
03301 
03302 
03303 
03304 
03305 
03306 
03307 
03308 
03309 


void *buffer, int count)); 


/* Relógio: obtém tempos do sistema ou (des)programa a execução de uma chamada de alarme. 


- PROTOTYPE( int sys times, (int proc nr, clock t *ptr)); 
- PROTOTYPECint sys setalarm, (clock t exp time, int abs time)); 


/* Atalhos para a chamada de sistema sys irqctiO. */ 
ádefine sys irqdisable(hook id) N 
sys irqctI(IRQ DISABLE, O, O, hook id) 
#define sys irqenable(hook id) N 
sys irqctI(IRQ ENABLE, O, O, hook id) 
tdefine sys irqsetpolicy(irq vec, policy, hook id) N 
sys irqctI(IRQ SETPOLICY, irq vec, policy, hook id) 
tdefine sys irqrmpolicy(irq vec, hook id) N 
sys irqctI(IRQ RMPOLICY, irq vec, O, hook id) 
- PROTOTYPE ( int sys irgctl, (int request, int irq vec, int policy, 
int *irq hook id) ); 


/* Atalhos para as chamadas de sistema sys vircopyQO e sys physcopy O. */ 
ádefine sys biosin(bios vir, dst vir, bytes) À 

sys vircopy(SELF, BIOS SEG, bios vir, SELF, D, dst vir, bytes) 
tdefine sys biosout(src vir, bios vir, bytes) \ 

sys vircopy(SELF, D, src vir, SELF, BIOS SEG, bios vir, bytes) 
tdefine sys datacopy(src proc, src vir, dst proc, dst vir, bytes) À 

sys vircopy(src proc, D, src vir, dst proc, D, dst vir, bytes) 
tdefine sys textcopy(src proc, src vir, dst proc, dst vir, bytes) À 

sys vircopy(src proc, T, src vir, dst proc, T, dst vir, bytes) 
ádefine sys stackcopy(src proc, src vir, dst proc, dst vir, bytes) \ 

sys vircopy(src proc, S, src vir, dst proc, S, dst vir, bytes) 
- PROTOTYPECint sys vircopy, (int src proc, int src seg, vir bytes src vir, 

int dst proc, int dst seg, vir bytes dst vir, phys bytes bytes)); 


tdefine sys abscopy(src phys, dst phys, bytes) N 
sys physcopy(NONE, PHYS SEG, src phys, NONE, PHYS SEG, dst phys, bytes) 
- PROTOTYPECint sys physcopy, (int src proc, int src seg, vir bytes src vir, 
int dst proc, int dst seg, vir bytes dst vir, phys bytes bytes)); 
- PROTOTYPECint sys memset, (unsigned long pattern, 
phys bytes base, phys bytes bytes)); 


/* Chamadas de cópia virtual / física vetorizadas. */ 

&if DEAD CODE /* parte da biblioteca ainda não implementada */ 

- PROTOTYPECint sys virvcopy, (phys cp req *vec ptr,int vec size,int *nr ok)); 
- PROTOTYPECint sys physvcopy, (phys cp req *vec ptr,int vec size,int “nr ok)); 
#endif 


_PROTOTYPE(int sys_umap, (int proc nr, int seg, vir bytes vir_addr, 
vir bytes bytes, phys bytes *phys addr)); 

- PROTOTYPECint sys segctl, (int *index, ul6 t *seg, vir bytes *off, 
phys bytes phys, vir bytes size)); 


/* Atalhos para a chamada de sistema sys getinfoO. */ 
#define sys getkmessages(dst) sys getinfo(GET KMESSAGES, dst, 0,0,0) 


tdefine sys getkinfo(dst) sys getinfo(GET KINFO, dst, 0,0,0) 
tdefine sys getmachine(dst) sys getinfo(GET MACHINE, dst, 0,0,0) 
tdefine sys getproctab(dst) sys getinfo(GET PROCTAB, dst, 0,0,0) 
tdefine sys getprivtab(dst) sys getinfo(GET PRIVTAB, dst, 0,0,0) 
tdefine sys getproc(dst,nr) sys getinfo(GET PROC, dst, 0,0, nr) 
#define sys getrandomness(dst) sys getinfo(GET RANDOMNESS, dst, 0,0,0) 
ádefine sys getimage(dst) sys getinfo(GET IMAGE, dst, 0,0,0) 


ádefine sys getirqhooks(dst) sys getinfo(GET IRQHOOKS, dst, 0,0,0) 


*/ 
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03310 
03311 
03312 
03313 
03314 
03315 
03316 
03317 
03318 
03319 
03320 
03321 
03322 
03323 
03324 
03325 
03326 
03327 
03328 
03329 
03330 
03331 
03332 
03333 
03334 
03335 
03336 
03337 
03338 
03339 
03340 
03341 
03342 
03343 
03344 
03345 
03346 
03347 
03348 
03349 


tdefine sys getmonparams(v,vl)sys getinfo(GET MONPARAMS, v,vl, 0,0) 

tdefine sys getschedinfo(vl,v2) sys getinfo(GET SCHEDINFO, v1,0, v2,0) 

tdefine sys getlocktimings(dst) sys getinfo(GET LOCKTIMING, dst, 0,0,0) 

tdefine sys getbiosbuffer(virp, sizep) sys getinfo(GET BIOSBUFFER, virp, N 
sizeof(*virp), sizep, sizeof(*“sizep)) 


- PROTOTYPECint 


/* Controle de 


sys getinfo, (int request, void *val ptr, int val Ten, 
void *val ptr2, int val Ten2) J; 


sinal. */ 


- PROTOTYPECint sys kill, (int proc, int sig) ); 

- PROTOTYPECint sys sigsend, (int proc nr, struct sigmsg “sig ctxt) ); 

- PROTOTYPECint sys sigreturn, (int proc nr, struct sigmsg “sig ctxt) ); 

- PROTOTYPECint sys getksig, (int *k proc nr, sigset t *k sig map) ); 

- PROTOTYPECint sys endksig, (int proc nr) ); 

/* NOTA: foram usadas duas estratégias diferentes para distinguir os tipos de 
* E/S de dispositivo "byte", "word", "Tong': esta última usa fdefine e resulta em uma 
* implementação menor, mas perde a verificação de tipo estática. 

*/ 

- PROTOTYPECint sys voutb, (pvb pair t *pvb pairs, int nr ports) J3 

- PROTOTYPECint sys_voutw, (pvw_pair_t *pvw_pairs, int nr ports) J; 

- PROTOTYPECint sys_voutl, (pvl_pair_t *pvl_pairs, int nr ports) J; 

- PROTOTYPECint sys vinb, (pvb_pair_t *pvb_pairs, int nr ports) Ja 

- PROTOTYPECint sys vinw, (pvw pair t *pvw pairs, int nr ports) J; 

- PROTOTYPECint sys_vinl, (pvl_pair_t *pvl_pairs, int nr ports) J; 

/* Atalhos para a chamada de sistema sys outO. */ 

ádefine sys outb(p,v) sys out((p), (unsigned long) (v), DIO BYTE) 

tdefine sys outw(p,v) sys out((p), (unsigned long) (v), DIO WORD) 

tdefine sys out](p,v) sys out((p), (unsigned long) (v), DIO LONG) 

- PROTOTYPECint sys out, (int port, unsigned long value, int type) 25 

/* Atalhos para a chamada de sistema sys inQO. */ 

tdefine sys inb(p,v) sys in((p), (unsigned long*) (v), DIO BYTE) 

tdefine sys inw(p,v) sys in((p), (unsigned long*) (v), DIO WORD) 

ádefine sys inl(p,v) sys in((p), (unsigned long*) (v), DIO LONG) 

-PROTOTYPECint sys in, (int port, unsigned Tong *value, int type) J3 


#endif /* _SYSLIB_H */ 


HHHHHHHHH HHHH H+H HHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


include/minix/sysutil.h 


HHHEHEHHHH+HHH H+H HH H+H HH HH H+ HHHH HH HHHH H+H HH ++ 


03400 
03401 
03402 
03403 


03404 
03405 
03406 
03407 
03408 
03409 
03410 
03411 
03412 
03413 
03414 


#ifndef _EXTRALIB_H 
#define _EXTRALIB_H 


/* Definições de biblioteca de sistema extras para suportar drivers de dispositivo e 


servidores. 


* Criado: 


15 de março de 2004 por Jorrit N. Herder 


* Alterações: 

* 31 de maio de 2005: adicionados printf, kputc (reposicionado de syslib) 
31 de maio de 2005: adicionado getuptime 

$ 18 de março de 2005: adicionado tickdelay 


i 01 de outubro de 2004: adicionados env_parse, env_prefix, env_panic 
i 13 de julho de 2004: adicionado fkey_ct1 
$ 28 de abril de 2004: adicionados report, panic 
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03415 31 de março de 2004: configurado como outras bibliotecas, como syslib 
03416 TÁ 

03417 

03418  /%==============>====>D=>="=2>D=>>D2D>2=>>02DD=>=2=D=2>====>=2=0=>======================* 
03419 * Funções auxiliares diversas. 

03420 Foniy 
03421 


03422 /* Valores de retorno para análise de ambiente. */ 


03423 #define EP BUF SIZE 128 /* buffer local para valor de ambiente */ 
03424 #define EP UNSET 0 /* variável não configurada */ 

03425 &define EP OFF 1 /* var = off */ 

03426 define EP ON 2 /* var = on (ou campo deixado em branco) */ 
03427 &define EP SET 3 /* var = 1:2:3 (campo preenchido) */ 

03428 define EP EGETKENV 4 /* sys getkenvO) falhou ... */ 

03429 

03430 | PROTOTYPE( void env setargs, (int argc, char *argv[]) J 
03431 _PROTOTYPEÇ int env get param, (char *key, char *value, int max size) ); 
03432 | PROTOTYPE( int env prefix, (char *env, char *prefix) ja 
03433 _PROTOTYPE(Ç void env panic, (char *key) J; 


03434 | PROTOTYPE( int env parse, (char *env, char *fmt, int field, long *param, 
03435 long min, Tong max) J; 


03437 #define fkey_map(fkeys, sfkeys) fkey ctICFKEY MAP, (fkeys), (sfkeys)) 
03438 ádefine fkey unmap(fkeys, sfkeys) fkey ctICFKEY UNMAP, (fkeys), (sfkeys)) 
03439 #define fkey events(fkeys, sfkeys) fkey ctICFKEY EVENTS, (fkeys), (sfkeys)) 


03440 | PROTOTYPE( int fkey ctl, (int req, int *fkeys, int *sfkeys) J; 
03441 
03442 _PROTOTYPEÇ int printf, (const char *fmt, ...)); 


03443 | PROTOTYPE( void kputc, (Cint c)); 

03444 _PROTOTYPEÇ void report, (char *who, char “mess, int num)); 
03445 _PROTOTYPEÇ void panic, (char *who, char *mess, int num)); 
03446 _PROTOTYPEÇ int getuptime, (clock t *ticks)); 

03447 _PROTOTYPEÇ int tickdelay, (clock t ticks)); 


03449 #endif /*  EXTRALIB H */ 


DO ssa Do o O O DD O HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO OO OD O O 
include/minix/callnr.h 
HHHHHEHHHHHHH + OD O DO AD DO HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ O O DD OO O O O DO 


03500 define NCALLS 91 /* número de chamadas de sistema permitidas */ 
03501 

03502 #define EXIT 
03503 #define FORK 
03504 #define READ 
03505 #define WRITE 
03506 #define OPEN 
03507 #define CLOSE 
03508 #define WAIT 
03509 #define CREAT 
03510 #define LINK 
03511 #define UNLINK 
03512 #define WAITPID 
03513 #define CHDIR 
03514 #define TIME 


LREBoocvauwuswnh 
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03515 
03516 
03517 
03518 
03519 
03520 
03521 
03522 
03523 
03524 
03525 
03526 
03527 
03528 
03529 
03530 
03531 
03532 
03533 
03534 
03535 
03536 
03537 
03538 
03539 
03540 
03541 
03542 
03543 
03544 
03545 
03546 
03547 
03548 
03549 
03550 
03551 
03552 
03553 
03554 
03555 
03556 
03557 
03558 
03559 
03560 
03561 
03562 
03563 
03564 
03565 
03566 
03567 
03568 
03569 
03570 
03571 
03572 
03573 
03574 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


/* O que segue não são chamadas de 
/* 
/* 
/* 


tdefine 
tdefine 
tdefine 


/* Tratamento de sinal Posix. 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


tdefine 


MKNOD 
CHMOD 
CHOWN 
BRK 
STAT 
LSEEK 
GETPID 
MOUNT 
UMOUNT 
SETUID 
GETUID 
STIME 
PTRACE 
ALARM 
FSTAT 
PAUSE 
UTIME 
ACCESS 
SYNC 
KILL 
RENAME 
MKDIR 
RMDIR 
DUP 
PIPE 
TIMES 
SETGID 
GETGID 
SIGNAL 
IOCTL 
FCNTL 
EXEC 
UMASK 
CHROOT 
SETSID 
GETPGRP 


UNPAUSE 
REVIVE 
TASK REPLY 


SIGACTION 
SIGSUSPEND 
SIGPENDING 
SIGPROCMASK 
SIGRETURN 


REBOOT 


65 
67 
68 


71 


“7 


sistema, mas são processadas como elas. */ 
para MM ou FS: verifica EINTR */ 

para FS: reanima um processo em repouso */ 
para FS: código de resposta da tarefa tty */ 


/* para PM */ 


/* chamadas específicas do MINIX, 


#define 


#define 
#define 
#define 
#define 
#define 
#define 


SVRCTL 


GETSYSINFO 
GETPROCNR 
DEVCTL 
FSTATFS 
ALLOCMEM 
FREEMEM 


77 


por exemplo, para suportar serviços de sistema. * 


/* não usado */ 


22225 


* para 
* para 
* para 
* para 
* para 
* para 


PM 
PM 
FS 
FS 
PM 
PM 


ou FS */ 
*/ 
*/ 
NA 
WA 
*/ 
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03575 #define SELECT 85 /* para FS */ 
03576 define FCHDIR 86 /* para FS */ 
03577 #define FSYNC 87 /* para FS*/ 
03578 define GETPRIORITY 88 /* para PM */ 
03579 #define SETPRIORITY 89 /* para PM*/ 
03580 define GETTIMEOFDAY 90 /* para PM */ 


HHHEHHHHEHHHH +H HHHH HHHH HHHH HHHH HHH H+H HH HHHH HHHH O O DD H+H O O O DD OO OO O O 
include/minix/com.h 
DO soa op o O O O O HEHHE HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH O O DO O OO O 


03600 #ifndef | MINIX COM H 
03601 define MINIX COM H 


03602 

03603 /*============== Y 
03604 i Números mágicos de processo i 
03605 ¥ S= Y / 
03606 

03607 #define ANY 0x7ace /* usado para indicar "qualquer processo” */ 
03608 gdefine NONE O0x6ace /* usado para indicar "absolutamente nenhum processo” */ 
03609 #define SELF Ox8ace /* usado para indicar "próprio processo’ */ 
03610 

03611 /*============================= Y 
03612 j Números de processos na imagem do sistema i 
03613 *============= Y / 
03614 


03615 /* Os valores de vários números de tarefa dependem dessas ou outras tarefas 
03616 * estarem ativadas. Eles são definidos como (PREVIOUS_TASK - ENABLE_TASK) em geral. 


03617 * ENABLE TASK é O ou 1, de modo que uma tarefa recebe um novo número ou 
03618 * o mesmo número da tarefa anterior e não é mais usado. Note que a 

03619 * ordem deve corresponder a ordem da tabela de tarefas definida em table.c. 
03620 */ 

03621 


03622 /* Tarefas do núcleo. Todas elas são executadas no mesmo espaço de endereçamento. */ 
03623 #define IDLE -4 /* executa quando mais nenhuma pode ser executada */ 
03624 #define CLOCK -3 /* alarmes e outras funções de relógio*/ 

03625 #define SYSTEM -2 /* solicita funcionalidade de sistema */ 

03626 #define KERNEL -1 /* pseudo-processo para IPC e escalonamento */ 

03627 #define HARDWARE KERNEL * para rotinas de tratamento de interrupção de hardware */ 
03628 

03629 /* Número de tarefas. Note que NR PROCS é definido em <minix/config.h>. */ 

03630 define NR TASKS 4 


03631 
03632 /* Processos em espaço de usuário; isto é, drivers de dispositivo, servidores e INIT. */ 
03633 #define PM PROC NR 0 /* gerenciador de processo */ 


03634 define FS PROC NR 
03635 #define RS PROC NR 
03636  ádefine MEM PROC NR 
03637 #define LOG PROC NR 
03638 #define TTY PROC NR 
03639 ádefine DRVR PROC NR 
03640 define INIT PROC NR 
03641 

03642 /* Número de processos contidos na imagem do sistema. */ 
03643 ádefine NR BOOT PROCS (NR TASKS + INIT PROC NR + 1) 
03644 


/* sistema de arquivo */ 

/* servidor de reencarnação */ 

/* driver de memória (disco de RAM, nulo etc.) */ 
/* driver de dispositivo de log */ 
J> 
/ 
/ 


driver de terminal (TTY) */ 
* driver de dispositivo para meio de inicialização */ 
* init -- vai para multiusuário */ 


NOUA UWNEe 
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03645 
03646 
03647 
03648 
03649 
03650 
03651 
03652 
03653 
03654 
03655 
03656 
03657 
03658 
03659 
03660 
03661 
03662 
03663 
03664 
03665 
03666 
03667 
03668 
03669 
03670 
03671 
03672 
03673 
03674 
03675 
03676 
03677 
03678 
03679 
03680 
03681 
03682 
03683 
03684 
03685 
03686 
03687 
03688 
03689 
03690 
03691 
03692 
03693 
03694 
03695 
03696 
03697 
03698 
03699 
03700 
03701 
03702 
03703 
03704 


/* Tipos de notificação do núcleo. Em princípio, eles podem ser enviados para qualquer 
* processo; portanto, certifique-se de que esses tipos não interfiram em outros tipos 
* de mensagem. As notificações são priorizadas por causa da maneira usada em unholdO e 
* notificações com bloqueio são distribuídas. Os números mais baixos aparecem primeiro. 


* O deslocamento é usado para os mapas de bits de notificação por processo. 


tdefine NOTIFY MESSAGE 0x1000 

tdefine NOTIFY FROM(p nr) (NOTIFY MESSAGE | (Cp nr) + NR TASKS)) 

& define SYN ALARM NOTIFY FROM(CLOCK) /* alarme síncrono */ 

& define SYS SIG NOTIFY FROM(SYSTEM) /* sinal do sistema */ 

& define HARD INT NOTIFY FROM(HARDWARE)  /* interrupção de hardware */ 

& define NEW KSIG NOTIFY FROM(HARDWARE)  /* novo sinal do núcleo */ 

# define FKEY PRESSED NOTIFY FROMCTTY PROC NR)/* pressionamento de tecla de função */ 


/* Atalhos para parâmetros de mensagem passados com notificações. */ 


tdefine NOTIFY SOURCE m source 
define NOTIFY TYPE m type 
define NOTIFY ARG m2 11 
ádefine NOTIFY TIMESTAMP m2 12 
define NOTIFY FLAGS m2 il 
PÁ O e À 

$ Mensagens para drivers de dispositivo BLOCK e CHARACTER x 

ý oS) 
/* Tipos de mensagem para drivers de dispositivo. */ 
#define DEV_RQ BASE 0x400 /* base para tipos de requisição de dispositivo */ 
#define DEV_RS_BASE 0x500 /* base para tipos de resposta de dispositivo */ 
#define CANCEL (DEV RQ BASE + 0) /* req. p/ forçar cancelamento de tarefa */ 
gdefine DEV READ (DEV RQ BASE + 3) /* lê do dispositivo secundário */ 
gdefine DEV WRITE (DEV RQ BASE + 4) /* escreve no dispositivo secundário */ 
define DEV. IOCTL (DEV. RQ BASE + 5) /* código de controle de E/S */ 
gdefine DEV OPEN (DEV RQ BASE + 6) /* abre um dispositivo secundário */ 
gdefine DEV CLOSE (DEV RQ BASE + 7) /* fecha um dispositivo secundário */ 
define DEV. SCATTER (DEV RQ BASE + 8) /* escreve de um vetor */ 
#define DEV. GATHER (DEV RQ BASE + 9) /* 1ê em um vetor */ 
tdefine TTY SETPGRP (DEV RQ BASE + 10) /* configura grupo de processos */ 
gdefine TTY EXIT (DEV RQ BASE + 11) /* o líder do grupo de processos saiu */ 
define DEV SELECT (DEV RQ BASE + 12) /* solicita atenção de select() */ 
tdefine DEV STATUS (DEV RQ BASE + 13) /* solicita status do driver */ 
ádefine DEV REPLY (DEV RS BASE + 0) /* resposta de tarefa geral */ 
define DEV CLONED (DEV RS BASE + 1) /* retorna secundário clonado */ 
define DEV REVIVE (DEV RS BASE * driver reanima processo */ 


define DEV IO READY (DEV RS BASE 
define DEV NO STATUS (DEV RS BASE 


3) /* dispositivo selecionado pronto */ 
4) /* resposta de status vazia */ 


++ +++ 
N 
w 
E 


/* Nomes de campo para mensagens para drivers de dispositivo de bloco e de caractere. */ 


ádefine DEVICE m2 il /* dispositivo principal-secundário */ 
tdefine PROC NR m2 i2 /* qual (processo) deseja E/S? */ 
tdefine COUNT m2 i3 /* quantos bytes vai transferir */ 
tdefine REQUEST m2 i3 /* código de requisição ioctl */ 
gdefine POSITION m2 11 /* deslocamento de arquivo */ 

tdefine ADDRESS m2 pl /* endereço do buffer do núcleo */ 
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03705 /* Nomes de campo para mensagens DEV SELECT para drivers de dispositivo. */ 
03706 define DEV MINOR m2 il /* dispositivo secundário */ 

03707 #define DEV SEL OPS m2 i2 /* quais operações de seleção são solicitadas */ 
03708 gdefine DEV SEL WATCH m2 13 /* pede notificação se nenhuma operação estiver pronta */ 
03709 

03710 /* Nomes de campo usados em mensagens de resposta de tarefas. */ 

03711 &define REP PROC NR m2 il /* número de processos em cujo nome a E/S foi feita */ 
03712 &define REP STATUS m2 i2 /* bytes transferidos ou número do erro */ 

03713 # define SUSPEND -998  /*status p/ suspender processo: responde depois*/ 
03714 

03715 /* Nomes de campo para mensagens para driver TTY. */ 

03716 #define TTY LINE DEVICE /* parâmetro de mensagem: Tinha de terminal */ 
03717 #define TTY REQUEST COUNT /* parâmetro de mensagem: código de requisição ioctl */ 
03718 #define TTY SPEK POSITION/* parâmetro de mensagem: velocidade de ioctl, apagando */ 
03719 #define TTY FLAGS m2 12 /* parâmetro de mensagem: modo tty ioctl */ 

03720 #define TTY PGRP m2 13 /* parâmetro de mensagem: grupo de processos */ 
03721 

03722 /* Nomes de campo para a resposta de status QIC 02 de driver de fita */ 

03723 &define TAPE STATO m2 11 

03724 #define TAPE STAT1 m2 12 

03725 

03726  /*====DDDDD>D>DDDDDDDDDDDDDD0DDDDDDDDDDD02D0DDDDDD0D0DDD=DD=D>02>=>=>=>=>>>>=>===>* 
03727 E Mensagens para camada de rede E 
03728 PEDE / 
03729 

037230 /* Tipos de mensagem para pedidos da camada de rede. Essa camada atua como um driver. */ 
03731 #define NW OPEN DEV OPEN 

03732 ádefine NW CLOSE DEV CLOSE 

03733 #define NW READ DEV READ 

03734 #define NW WRITE DEV WRITE 

03735 #define NW IOCTL DEV IOCTL 

03736 #define NW CANCEL CANCEL 

03737 

037238 /* Tipo de base para requisições e respostas da camada de enlace de dados. */ 
03739 gdefine DL RQ BASE 0x800 

03740 #define DL RS BASE 0x900 

03741 

03742 /* Tipos de mensagem para requisições da camada de enlace de dados. */ 

03743 #define DL WRITE (DL RQ BASE + 3) 

03744 #define DL WRITEV (DL RQ BASE + 4) 

03745 #define DL READ (DL RQ BASE + 5) 

03746 #define DL READV (DL RQ BASE + 6) 

03747 #define DL INIT (DL RQ BASE + 7) 

03748 ádefine DL STOP (DL RQ BASE + 8) 

03749 #define DL GETSTAT (DL RQ BASE + 9) 

03750 

03751 /* Tipo de mensagem para respostas da camada de enlace de dados. */ 

03752 ádefine DL INIT REPLY (DL RS BASE + 20) 

03753 define DL TASK REPLY (DL RS BASE + 21) 

03754 

03755 /* Nomes de campo para mensagens da camada de enlace de dados. */ 

03756  &define DL PORT m2 il 

03757 &define DL PROC m2 i2 

03758 #define DL COUNT m2 13 

03759 #define DL MODE m2 11 

03760 #define DL CLCK m2 12 

03761 define DL ADDR m2 pl 

03762 define DL STAT m2 11 

03763 

03764 /* Bits no campo'DL STAT' de respostas DL. 
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03765 
03766 
03767 
03768 
03769 
03770 
03771 
03772 
03773 
03774 
03775 
03776 
03777 
03778 
03779 
03780 
03781 
03782 
03783 
03784 
03785 
03786 
03787 
03788 
03789 
03790 
03791 
03792 
03793 
03794 
03795 
03796 
03797 
03798 
03799 
03800 
03801 
03802 
03803 
03804 
03805 
03806 
03807 
03808 
03809 
03810 
03811 
03812 
03813 
03814 
03815 
03816 
03817 
03818 
03819 
03820 
03821 
03822 
03823 
03824 


& define DL PACK SEND 0x01 

& define DL PACK RECV 0x02 

& define DL READ IP 0x04 

/* Bits no campo'DL MODE" de requisições DL. */ 

# define DL NOMODE 0x0 

# define DL_PROMISC_REQ 0x2 

# define DL_MULTI_REQ 0x4 

# define DL_BROAD_REQ 0x8 

[É === 


/* As chamadas da biblioteca de sistema são despachadas por meio de um vetor de chamada; 


* portanto, cuidado ao modificar os números de chamada de sistema. Os números aqui 


* determinam qual chamada é feita a partir do vetor de chamada. 


*/ 


#define KERNEL_CALL 


define 
define 
define 
define 
define 
define 
define 


HH HH i HH 


define 
define 
define 
define 


HH Ho H 


define 
define 
define 


$ HH 


define 
define 
define 
define 
define 


HH HH Ho H 


define 
define 
define 
define 
define 


HH HH HH * 


define 
define 
define 
define 


Ho Ho HH 


SYS FORK 
SYS EXEC 
SYS EXIT 
SYS NICE 
SYS PRIVCTL 
SYS TRACE 
SYS KILL 


SYS GETKSIG 
SYS ENDKSIG 
SYS SIGSEND 
SYS. SIGRETURN 


SYS NEWMAP 
SYS SEGCTL 
SYS MEMSET 


SYS UMAP 

SYS VIRCOPY 
SYS. PHYSCOPY 
SYS VIRVCOPY 
SYS. PHYSVCOPY 


SYS. IRQCTL 
SYS INT86 
SYS. DEVIO 
SYS SDEVIO 
SYS VDEVIO 


SYS. SETALARM 
SYS. TIMES 
SYS GETINFO 
SYS. ABORT 


ádefine NR SYS CALLS 


/* Nomes de campo for SYS MEMSET, SYS SEGCTL. 


gdefine MEM PTR 
tdefine MEM COUNT 
tdefine MEM PATTERN 


0x600 


CKERNEL CALL 
CKERNEL CALL 
CKERNEL CALL 
CKERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 
CKERNEL CALL 


(KERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 


CKERNEL CALL 
CKERNEL CALL 
CKERNEL CALL 


CKERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 
CKERNEL CALL 
(KERNEL CALL 


CKERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 
CKERNEL CALL 
CKERNEL CALL 


(KERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 
(KERNEL CALL 


28 /* 
m2 pl 


m2 11 /* 
m2 12 


++ +++ ++ 


+++ ++ 


+ 
+ 
+ 
+ 


0) 
1) 
2) 
3) 
4) 


24) 
25) 
26) 
27) 


/* base */ 
contador */ 
/* padrão a escrever */ 


/* 
/* 
/* 
/* 
/ * 
/ * 
/* 


/* 
/* 
/* 
/* 


/* 
/* 


* sys_memset() */ 


*/ 


sys forkO */ 
sys exec() */ 
sys exitO */ 
sys nice() */ 


sys privetlO */ 


sys trace() */ 
sys KITO */ 


sys getsigO */ 
sys endsigO */ 


sys sigsend(O */ 
sys sigreturnO */ 


sys newmapO */ 
sys segctl(O) */ 


* sys umapO */ 

* sys vircopyO */ 
* sys physcopyO */ 
* sys virvcopy(O */ 
* sys physvcopyO */ 


* sys irgctlO */ 
* sys int860 */ 
* sys devio() */ 
* sys sdevio() */ 
* sys vdevio() */ 


* sys setalarm() */ 
* sys times */ 
* sys getinfoO) */ 
* sys abort() */ 


número de chamadas de sistema */ 


/* base para chamadas do núcleo para SYSTEM */ 
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03825 
03826 
03827 
03828 
03829 
03830 
03831 
03832 
03833 
03834 
03835 
03836 
03837 
03838 
03839 
03840 
03841 
03842 
03843 
03844 
03845 
03846 
03847 
03848 
03849 
03850 
03851 
03852 
03853 
03854 
03855 
03856 
03857 
03858 
03859 
03860 
03861 
03862 
03863 
03864 
03865 
03866 
03867 
03868 
03869 
03870 
03871 
03872 
03873 
03874 
03875 
03876 
03877 
03878 
03879 
03880 
03881 
03882 
03883 
03884 


define MEM CHUNK BASE 
define MEM CHUNK SIZE 
define MEM TOT SIZE 

define MEM CHUNK TAG 


/* 
/* 


/* Nomes de campo para SYS DEVIO, 


tdefine DIO REQUEST 
# define DIO_INPUT 
& define DIO OUTPUT 
tdefine DIO TYPE 

& define DIO BYTE 
& define DIO WORD 
& define DIO LONG 
tdefine DIO PORT 
tdefine DIO VALUE 
tdefine DIO VEC ADDR 
tdefine DIO VEC SIZE 
tdefine DIO VEC PROC 


/* 


* endereço de base físico */ 

* tamanho do trecho de memória */ 

tamanho total da memória */ 

tag para identificar trecho de memória */ 


SYS_VDEVIO, SYS SDEVIO. */ 

* entrada ou saída de dispositivo */ 

* entrada */ 

* saída */ 

* flag indicando byte, word or long */ 
* valores de tipo byte */ 

* valores de tipo word */ 

* valores de tipo long */ 

* endereço de porta único */ 

* valor de E/S único */ 

endereço de buffer ou pares (p,v) */ 
* número de elementos no vetor */ 

* número de processo onde o vetor está */ 


/* Nomes de campo para SYS SIGNARLM, SYS FLAGARLM, SYS SYNCALRM. */ 


define ALRM EXP TIME 
define ALRM ABS TIME 
define ALRM TIME LEFT 
define ALRM PROC NR 
define ALRM FLAG PTR 


/* 


/* 


* tempo de expiração para a chamada de alarme */ 
configura como 1 para usar tempo de alarme absoluto */ 
* quantos tiques estavam restando */ 

* qual processo deseja o alarme? */ 

endereço virtual do flag de tempo limite */ 


/* Nomes de campo para SYS_IRQCTL. */ 


#define IRQ REQUEST 

# define IRQ SETPOLICY 
# define IRQ RMPOLICY 
# define IRQ ENABLE 

# define IRQ DISABLE 
#define IRQ VECTOR 
#define IRQ POLICY 

# define IRQ REENABLE 
# define IRQ BYTE 

# define IRQ WORD 

# define IRQ LONG 
#define IRQ PROC NR 
#define IRQ HOOK ID 


/* 


/* 


/* 
/* 


* o que fazer? */ 

* gerencia uma entrada da tabela de IRQs */ 
remove uma entrada da tabela de IRQs */ 

* ativa interrupções */ 

* desativa interrupções */ 

* vetor de irq */ 

* opções para requisições IRQCTL */ 

reativa linha de IRQ após a interrupção */ 
* valores byte */ 

* valores word */ 

* valores long */ 

número do processo, SELF, NONE */ 

id do gancho de irq no núcleo */ 


/* Nomes de campo para SYS SEGCTL. */ 


gdefine SEG SELECT 
tdefine SEG OFFSET 
tdefine SEG PHYS 
tdefine SEG SIZE 
tdefine SEG INDEX 


/* 


/* 


seletor de segmento retornado */ 

* deslocamento no segmento returned */ 
* endereço físico do segmento */ 

* tamanho do segmento */ 

índice do segmento no mapa remoto */ 


/* Nomes de campo para SYS_VIDCOPY. */ 


#define VID_REQUEST 
# define VID_VID_COPY 
# define MEM_VID_COPY 
#define VID_SRC_ADDR 
#define VID_SRC_OFFSET 
#define VID_DST_OFFSET 
#define VID_CP_COUNT 


/* 
/* 
/* 


/* 


/* Nomes de campo para SYS_ABORT. 


#define ABRT_HOW 
#define ABRT_MON_PROC 


m4_11 / 
m4_12 / 
m4_13 
m4_14 
m2_i3 / 
0o / 
1. 7 
mil / 
bo y 
wo y 
Voy 
ma 11 / 
mo 12 / 
m2 pl 
mo 12 / 
m2_i2 / 
m2_11 / 
m2_i2 
m2_11 / 
mii / 
m2_p1 
m5_c1 / 
1 
2 
3 y 
4 / 
m5_c2 / 
m5_il / 
0x001 
0x100 / 
0x200 / 
0x400 / 
m5_i2 
m5_13 
m4_11 
m4_12 / 
m4_13 / 
m4_l14 / 
m4_15 
m4_11 / 
1 
2 
m4_12 
m4_13 / 
m4_l4 / 
m4_15 
mLil / 
ml_i2 / 


* o que fazer? */ 

solicita vid vid copyO */ 

solicita mem vid copyO */ 

endereço virtual na memória */ 

* deslocamento na memória de vídeo */ 

* deslocamento na memória de vídeo */ 
número de palavras a serem copiadas */ 


*/ 
* RBT REBOOT, RBT HALT, etc. */ 
* processo onde estão os parâmetros do monitor */ 
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03885 
03886 
03887 
03888 
03889 
03890 
03891 
03892 
03893 
03894 
03895 
03896 
03897 
03898 
03899 
03900 
03901 
03902 
03903 
03904 
03905 
03906 
03907 
03908 
03909 
03910 
03911 
03912 
03913 
03914 
03915 
03916 
03917 
03918 
03919 
03920 
03921 
03922 
03923 
03924 
03925 
03926 
03927 
03928 
03929 
03930 
03931 
03932 
03933 
03934 
03935 
03936 
03937 
03938 
03939 
03940 
03941 
03942 
03943 
03944 


define ABRT MON LEN 
define ABRT MON ADDR 


mi i3 
mi pl 


/* Nomes de campo para  UMAP, 
tdefine CP SRC SPACE m5 cl 
tdefine CP SRC PROC NR m5 il 
tdefine CP SRC ADDR m5 11 /* 
tdefine CP DST SPACE m5. c2 /* 
tdefine CP DST PROC NR m5 i2 
tdefine CP DST ADDR m5 12 
tdefine CP NR BYTES m5_13 /* 


_VIRCOPY, _ 
/* espaço T ou 
/* processo do qual copiar */ 

endereço de onde vêm os dados */ 

espaço T ou D (pilha também é D) */ 

/* processo no qual copiar */ 

/* endereço para onde vão os dados */ 

número de bytes a copiar */ 


/* comprimento dos parâmetros do monitor */ 
/* endereço virtual dos parâmetros do monitor */ 


PHYSCOPY. */ 
D (pilha também é D) */ 


/* Nomes de campo para SYS_VCOPY e SYS_VVIRCOPY. */ 


#define VCP_NR_OK 
#define VCP_VEC_SIZE 
#define VCP_VEC_ADDR 


mi i2 /* 
ml i3 
mi pi 


/* Nomes de campo para SYS GETINFO. */ 


tdefine I REQUEST m7 13 /* quais 
& define GET KINFO 0 /* obtém 
& define GET IMAGE T /* obtém 
& define GET PROCTAB 2 /* obtém 
& define GET RANDOMNESS 3 /* obtém 
& define GET MONPARAMS 4 /* obtém 
& define GET KENV 5 /* obtém 
& define GET IRQHOOKS 6 /* obtém 
& define GET KMESSAGES 7 /* obtém 
& define GET PRIVTAB 8 /* obtém 
& define GET KADDRESSES 9 /* obtém 
& define GET SCHEDINFO 10 /* obtém 
& define GET PROC 11 /* obtém 
& define GET MACHINE 12 /* obtém 
& define GET LOCKTIMING 13 /* obtém 
# define GET_BIOSBUFFER 14 /* obtém 
#define I_PROC_NR m7_i4 

#define I_VAL_PTR m7_p1 

#define I_VAL_LEN m7 il 

#define I VAL PTR2 m7 p2 

gdefine I VAL LEN2 m7 12 /* 


/* Nomes de campo para SYS TIMES. */ 


#define T PROC NR mg 11 

tdefine T USER TIME m4 11 /* tempo 
tdefine T SYSTEM TIME m4 12 /* tempo 
tdefine T CHILD UTIME m4 13 /* tempo 
#define T CHILD STIME m4 14 /* tempo 
tdefine T BOOT TICKS m4 15 /* 


número de cópias bem-sucedidas */ 
/* tamanho do vetor de cópia */ 
/* ponteiro para o vetor de cópia */ 


informações vai obter */ 
estrutura de informações do núcleo */ 
tabela de imagem do sistema */ 
tabela de processos do núcleo */ 
buffer aleatório */ 

parâmetros do monitor */ 

string de ambiente do núcleo */ 

a tabela de IRQs */ 

mensagens do núcleo*/ 

tabela de privilégios do núcleo */ 
vários endereços do núcleo */ 
filas de escalonamento */ 


entrada de processo se for dado o processo */ 


informações da máquina */ 


sincronismos de latência de lock()/unlockO) */ 


um buffer para chamadas da BIOS */ 


/* processo que fez a chamada */ 
/* endereço virtual no processo que fez a chamada */ 
/* comprimento máximo do valor */ 

/* segundo endereço virtual */ 

segundo comprimento ou número do processo */ 


/* processo para solicitar informações de tempo */ 


de usuário consumido 
de sistema consumido 
de usuário consumido 
de sistema consumido 


pelo processo */ 
pelo processo */ 


/* Nomes de campo para SYS TRACE, SYS SVRCTL. */ 


tdefine CTL PROC NR m2 il /* 


tdefine CTL REQUEST m2 i2 7 
#define CTL_MM_PRIV m2_i3 / 
tdefine CTL ARG PTR m2 pl Fái 
#define CTL_ADDRESS m2_11 Fá: 
tdefine CTL DATA m2 12 /* campo 


número de processo que fez a chamada */ 
requisição de controle de servidor */ 

* privilégio visto pelo PM */ 

* ponteiro para argumento */ 

* endereço no espaço do processo monitorado */ 


de dados para monitoramento */ 


/* Nomes de campo para SYS KILL, SYS SIGCTL */ 


tdefine SIG REQUEST m2 12 /* 
tdefine S GETSIG 0 /* obtém 
tdefine S ENDSIG 1 


requisição de controle de sinal de PM */ 


sinal do núcleo pendente */ 


/* termina um sinal do núcleo */ 


pelos filhos do processo */ 
pelos filhos do processo */ 
número de tiques de relógio desde a inicialização */ 
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03945 
03946 
03947 
03948 
03949 
03950 
03951 
03952 
03953 
03954 
03955 
03956 
03957 
03958 
03959 
03960 
03961 
03962 
03963 
03964 
03965 
03966 
03967 
03968 
03969 
03970 
03971 
03972 
03973 
03974 
03975 
03976 
03977 
03978 
03979 
03980 
03981 
03982 
03983 
03984 
03985 
03986 
03987 
03988 
03989 
03990 
03991 
03992 
03993 
03994 
03995 
03996 
03997 
03998 
03999 
04000 
04001 
04002 
04003 
04004 


tdefine S SENDSIG 2 /* tratamento de sinal estilo POSIX */ 

gdefine S SIGRETURN 3 /* retorno do tratamento POSIX */ 

tdefine S KILL 4 /* servidores eliminam processo com sinal */ 

tdefine SIG PROC m2 il /* número de processo para informação */ 

tdefine SIG NUMBER m2 i2 /* número de sinal a enviar */ 

tdefine SIG FLAGS m2 i3 /* campo de flags de sinal */ 

tdefine SIG MAP m2 11 /* usado pelo núcleo para passar mapa de bits de sinal 
#define SIG CTXT PTR m2 pl /* ponteiro para restaurar contexto de sinal */ 


/* Nomes de campo para SYS FORK,  EXEC,  EXIT,  NEWMAP. */ 


*/ 


#define PR_PROC_NR mi il /* indica um processo (filho) */ 

ádefine PR PRIORITY mi i2 /* prioridade do processo */ 

define PR PPROC NR mi i2 /* indica um processo (pai) */ 

ádefine PR PID ml i3 /* id de processo no gerenciador de processos */ 

define PR STACK PTR ml pl /* usado para ponteiro de pilha em sys exec, sys getsp */ 
tdefine PR TRACING mi i3 /* flag indicativo se monitoramento está lig./deslig. */ 
define PR NAME PTR mi p2 /* informa onde está o nome do programa para dump */ 
define PR IP PTR ml p3 /* valor inicial de ip após a execução */ 

tdefine PR MEM PTR mi pi /* informa onde está o mapa de memória para sys newmap */ 


/* Nomes de campo para SYS INT86 */ 
ádefine INT86 REG86 mi pl /* ponteiro para registradores */ 


/* Nomes de campo para SELECT (FS). */ 
tdefine SEL NFDS m8 il 
tdefine SEL READFDS m8 pl 
ádefine SEL WRITEFDS  m8 p2 
#define SEL ERRORFDS  m8 p3 
tdefine SEL TIMEOUT m8 p4 


J" ma 
x Mensagens para servidor de gerenciamento de sistema x 
ea EEA O E TE A S / 
#define SRV_RQ BASE 0x700 
#define SRV_UP CSRV_RQ_BASE + 0) /* inicia serviço de sistema */ 
#define SRV_DOWN CSRV RQ BASE + 1) /* pára serviço de sistema */ 
#define SRV. STATUS (SRV RQ BASE + 2) /* obtém status do serviço */ 
# define SRV PATH ADDR mi pi /* caminho do binário */ 
# define SRV PATH LEN mi il /* comprimento do binário */ 
# define SRV ARGS ADDR ml. p2 /* argumentos a serem passados */ 
# define SRV ARGS LEN ml i2 /* comprimento dos argumentos */ 
# define SRV DEV MAJOR ml 13 /* número principal do dispositivo */ 
# define SRV. PRIV ADDR ml. p3 /* string de privilégios */ 
# define SRV PRIV LEN ml 13 /* comprimento dos privilégios */ 


* === / 
/* Tipos de requisições e nomes de campo usados, por exemplo, pelo IS. */ 

#define PANIC_DUMPS 97 /* dump de depuração no TTY em RBT_PANIC */ 
# define FKEY_CONTROL 98 /* controla uma tecla de função no TTY */ 

# define FKEY_REQUEST m2 il /* requisição para executar em TTY */ 

# define FKEY MAP 10 /* observa tecla de função */ 

# define FKEY UNMAP 11 /* pára de observar tecla de função */ 

# define FKEY EVENTS 12 /* solicita pressionamentos de tecla abertos */ 
# define FKEY FKEYS m2 11 /* teclas F1-F12 pressionadas */ 
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04005 
04006 
04007 
04008 
04009 
04010 
04011 


& define FKEY SFKEYS m2 12 /* teclas Shift-F1-F12 pressionadas */ 
ádefine DIAGNOSTICS 100 /* produz uma string na saída sem o FS no meio */ 
# define DIAG PRINT BUF mi pi 

# define DIAG BUF COUNT mi il 

# define DIAG PROC NR mi i2 


gendif /*  MINIX COM H */ 


AAA ++ 


include/minix/devio.h 


AAA ++ 


04100 
04101 
04102 
04103 
04104 
04105 
04106 
04107 
04108 
04109 
04110 
04111 
04112 
04113 
04114 
04115 
04116 
04117 
04118 
04119 
04120 
04121 
04122 
04123 
04124 
04125 
04126 
04127 
04128 
04129 


/* Este arquivo fornece tipos básicos e algumas constantes para as 
* chamadas de sistema SYS DEVIO e SYS VDEVIO, as quais permitem aos 
* processos em nível de usuário executar E/S de dispositivo. 


* Criado: 
x 08 de abril de 2004 por Jorrit N. Herder 
*/ 


tifndef _DEVIO_H 
tdefine _DEVIO_H 


ginclude <minix/sys config.h> /* necessário para incluir <minix/type.h> */ 
#include <sys/types.h> /* u8_t, ul6 t, u32_t necessários */ 


typedef ul6 t port_t; 
typedef U16 t Port_t; 


/* Temos diferentes granularidades de E/S de porta: 8, 16, 32 bits. 
* Veja também <ibm/portio.h>, que tem funções para valores byte, word 
* e long. Assim, precisamos de diferentes tipos de par (porta,valor). 
*/ 

typedef struct { ul6 t port; u8 t value; } pvb pair t; 

typedef struct { ul6 t port; ul6 t value; } pvw pair t; 

typedef struct { ul6 t port; u32 t value; 3 pvl pair t; 


/* Atalho de macro para configurar o par (porta,valor). */ 
ádefine pv set(pv, p, v) CCpv).port = (p), Cpv).value = (v)) 
tdefine pv ptr set(pv ptr, p, v) CCpv ptr)->port = (p), (pv ptr)->value = (v)) 


gendif /* DEVIO H */ 


HHHEHEHHHHHH H+ HHHH HHHH HH H+ HH HHH HH HHHH HHHH HHHH H+H HHHH H+ HHH H+ +HH+HH+H+H+H+H+H+H+H+H+ 


include/minix/dmap.h 


HHHHHHHHH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


04200 
04201 
04202 
04203 
04204 
04205 


#ifndef _DMAP_H 
#define _DMAP_H 


#include <minix/sys_config.h> 
#include <minix/ipc.h> 
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04206 — /*=================>==>=>="=>=>>=2=D>="D2=>D=>22=D=>=="=>D=============2========>========* 

04207 x Tabela de Dispositivos <-> Driver hd 

04208 R a CDS D DOCES E SEDES SDS DDSDSDD=eDCS= DEDE DSSEScEcn=D= === / 

04209 

04210 /* Tabela de dispositivos. Essa tabela é indexada pelo número principal do dispositivo. Ela 
04211 * fornece o vínculo entre números principais de dispositivo e as rotinas que os processam. 
04212 * A tabela pode ser atualizada dinamicamente. O campo "dmap flags” descreve o 

04213 * status corrente de uma entrada e determina quais opções de controle são possíveis. 
04214 */ 

04215 #define DMAP MUTABLE 0x01 /* o mapeamento pode ser alcançado */ 

04216 define DMAP BUSY 0x02 /* driver ocupado com requisição */ 

04217 

04218 enum dev style { STYLE DEV, STYLE NDEV, STYLE TTY, STYLE CLONE 3; 

04219 


04220 extern struct dmap { 

04221 int _PROTOTYPE ((*dmap_opcl), Cint, Dev_t, int, int) ); 

04222 void _PROTOTYPE ((*dmap_io), (int, message *) ); 

04223 int dmap_driver; 

04224 int dmap_flags; 

04225 } dmap[]; 

04226 

04227 JF 
04228 $ Números de dispositivo principal e secundário 
04229 $ DEAA / 
04230 

04231 /* Número total de dispositivos diferentes. */ 

04232 #define NR_DEVICES 32 /* número de dispositivos (principal) */ 
04233 

04234 /* Números de dispositivo principal e secundário para driver MEMORY. */ 

04235 #define MEMORY MAJOR /* dispositivo principal para /dev/mem */ 
04236 # define RAM DEV /* dispositivo secundário para /dev/ram */ 
04237 # define MEM DEV /* dispositivo secundário para /dev/mem */ 
/* dispositivo secundário para /dev/kmem */ 
/ 

A 

/ 


vrwUNHON 


04238 # define KMEM DEV 

04239 # define NULL DEV * dispositivo secundário para /dev/null */ 
04240 # define BOOT DEV * dispositivo secundário para /dev/boot */ 
04241 # define ZERO DEV * dispositivo secundário para /dev/zero */ 
04242 


04243 define CTRLR(n) ((n)==0 ? 3 : (8 + 2*((n)-1))) /* fórmula mágica */ 
04244 
04245 /* Número de dispositivo especiais para o monitor de inicialização e para o FS. */ 


04246 # define DEV RAM 0x0100 /* número de dispositivo de /dev/ram */ 
04247 # define DEV BOOT 0x0104 * número de dispositivo de /dev/boot */ 
04248 

04249 #define FLOPPY MAJOR 2 /* dispositivo principal para disquetes */ 
04250 #define TTY MAJOR 4 /* dispositivo principal para ttys */ 

04251 #define CTTY MAJOR 5 /* dispositivo principal para /dev/tty */ 
04252 

04253 #define INET MAJOR 7 /* dispositivo principal para inet */ 

04254 

04255 gdefine LOG MAJOR 15 /* dispositivo principal para driver de log */ 
04256 # define IS KLOG DEV 0 /* dispositivo secundário para /dev/klog */ 
04257 


04258 #endif /* DMAP H */ 
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AAA ++ 


include/ibm/portio.h 


HEHEHEHEH HHHH HHHH HHHH H+H HH HH HH HH HHHH H+H HH HHHH HHHH HHHH H+ HH HH+HHH+HH+H+HH+H+H+H+H+H+ 


04300 
04301 
04302 
04303 
04304 
04305 
04306 
04307 
04308 
04309 
04310 
04311 
04312 
04313 
04314 
04315 
04316 
04317 
04318 
04319 
04320 
04321 
04322 
04323 
04324 
04325 
04326 
04327 
04328 


/* 
ibm/portio.h 


Criado: 15 de janeiro de 1992 por Philip Homburg 
*/ 


tifndef - PORTIO H. 
tdefine _PORTIO_H_ 


tifndef |. TYPES H 
#include <sys/types.h> 
#endif 


unsigned inb(U16_t port); 

unsigned inw(U16 t port); 

unsigned inl(U32 t port); 

void outb(U16 t port, U8 t value); 

void outw(U16 t port, U16 t value); 

void outT(U16 t port, U32 t value); 

void insb(U16 t port, void * buf, size t count); 

void insw(U16 t port, void * buf, size t count); 

void insl(U16 t port, void * buf, size_t count); 

void outsb(U16 t port, void * buf, size t count); 
void outsw(U16 t port, void * buf, size_t count); 
void outsl(U16 t port, void * buf, size_t count); 
void intr disable(void); 

void intr enable(void); 


gendif /* PORTIO H */ 


HEHEHEHEHE HH HHHH HHHH HH H HH HHHH H+H HHHH HHHH HHHH H+H HHHH HHHH HHHH H+H+HH+H+H+H+H+H+ 


include/ibm/interrupt.h 


HEHEHEHEH HHHH HHHH HH HH HH H+ HH HHH HH HHHH HHHH HHHH H+H HHHH HHHH HHHH HH+H+HH+H+H+H+H+H+ 


04400 
04401 
04402 
04403 
04404 
04405 
04406 
04407 
04408 
04409 
04410 
04411 
04412 
04413 
04414 
04415 
04416 
04417 
04418 
04419 


/* Números de interrupção e vetores de hardware. */ 


#ifndef _INTERRUPT_H 
#define _INTERRUPT_H 


#if (CHIP == INTEL) 


/* portas da controladora de interrupção 8259A. */ 


#define INT_CTL 0x20 /* porta de E/S da controladora de interrupção */ 
#define INT_CTLMASK 0x21 /* ativar bits nessa porta desativa valores int */ 
#define INT2_CTL OxAO /* porta de E/S p/ segunda controladora de interrupção 
tdefine INT2 CTLMASK 0xAL /* ativar bits nessa porta desativa os valores int */ 


/* Números mágicos para a controladora de interrupção. */ 
ádefine END OF INT 0x20 /* código usado para reativar após uma interrupção */ 


/* Vetores de interrupção definidos/reservados pelo processador. */ 
tdefine DIVIDE VECTOR 0 /* erro de divisão */ 

tdefine DEBUG VECTOR 1 /* passo único (monitoramento) */ 
tdefine NMI VECTOR 2 /* interrupção não mascarável */ 


*/ 
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04420 define BREAKPOINT VECTOR 3 /* ponto de interrupção de software */ 

04421 define OVERFLOW VECTOR 4 /* de INTO */ 

04422 

04423 /* Vetor de chamada de sistema */ 

04424 define SYS VECTOR 32 /* as chamadas de sistema são feitas com int SYSVEC */ 
04425 define SYS386 VECTOR 33 /* exceto quanto ao 386, as chamadas de sistema usam isto */ 
04426 define LEVELO VECTOR 34 /* para execução de uma função no nível O */ 

04427 


04428 /* Bases de irq conveniente para interrupções de hardware. Reprograma a(s) 8259(s) a 
04429 * partir dos padrões da BIOS do PC, pois a BIOS não respeita todos os vetores 

04430 * reservados do processador (de 0 a 31). 

04431 */ 

04432 define BIOS IRQO VEC 0x08 /* base de vetores IRQO-7 usados pela BIOS */ 

04433 define BIOS IRQ8 VEC 0x70 /* base de vetores IRQ8-15 usados pela BIOS */ 


04434 define IRQO VECTOR 0x50 /* vetores ótimos para reposicionar IRQO-7 */ 
04435 define IRQ8 VECTOR 0x70 /* não precisa para mover IRQ8-15 */ 
04436 


04437 /* Números de interrupção de hardware. */ 
04438 #define NR IRQ VECTORS 16 


04439 #define CLOCK IRQ 0 

04440 #define KEYBOARD IRQ 1 

04441 #define CASCADE IRQ 2 /* cascata ativa para 22 controladora AT */ 
04442 define ETHER IRQ 3 /* vetor de interrupção ethernet padrão */ 
04443 #define SECONDARY IRQ 3 /* vetor de interrupção RS232 para porta 2 */ 
04444 define RS232 IRQ 4 /* vetor de interrupção RS232 para porta 1 */ 
04445 define XT WINI IRQ 5 /* winchester do xt */ 

04446 define FLOPPY IRQ 6 /* disquete */ 

04447 #define PRINTER IRQ 7 

04448 define AT WINI O IRQ 14 /* na controladora O do winchester */ 

04449 define AT WINI 1 IRQ 15 /* na controladora 1 do winchester */ 


04450 
04451 /* Número de interrupção para vetor de hardware. */ 
04452 #define BIOS VECTORCirg) N 


04453 CCCirg) < 8 ? BIOS IRQO VEC : BIOS IRQ8 VEC) + (Cirq) & 0x07)) 
04454 #define VECTORCirg) N 

04455 CCCirq) < 8 ? IRQO VECTOR : IRQ8 VECTOR) + (Cirq) & 0x07)) 
04456 

04457 #endif /* (CHIP == INTEL) */ 

04458 


04459 #endif /* INTERRUPT H */ 


AAA 
include/ibm/ports.h 
HHHEHEHHHHHHH DO OD O DO AD DO HHHH HHHH HHH HHHH HHHH HHHH O DD O O O O DO OO OO O O 


04500 /* Endereços e números mágicos para portas diversas. */ 
04501 

04502 &ifndef | PORTS H 

04503 &define PORTS H 


04504 

04505 #if (CHIP == INTEL) 

04506 

04507 /* Portas diversas. */ 

04508 define PCR 0x65 /* Registrador de Controle Planar */ 

04509 &define PORT B 0x61 /* porta de E/S: porta B do 8255 (teclado, bip...) */ 
04510 gdefine TIMERO 0x40 /* porta de E/S para canal de temporizador 0 */ 

04511 define TIMERZ 0x42 /* porta de E/S para canal de temporizador 2 */ 

04512 define TIMER MODE 0x43 /* porta de E/S para controle de modo do temporizador */ 
04513 


04514 #endif /* (CHIP == INTEL) */ 
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04515 
04516 


gendif /* PORTS H */ 


HEHEHEHEH HHHH H+H HH HHH HH HH HH HH HHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH H+H+HH+HH+H+HH+H+H+H+H+H+ 


kernel/kernel.h 


HHHHHHHHH HHHH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH H+H HHHH HHHH HHHH HHHH HH+H+HH+H+H+H+H+H+ 


04600 
04601 
04602 
04603 
04604 
04605 
04606 
04607 
04608 
04609 
04610 
04611 
04612 
04613 
04614 
04615 
04616 
04617 
04618 
04619 
04620 
04621 
04622 
04623 
04624 
04625 
04626 
04627 
04628 
04629 
04630 
04631 


#ifndef KERNEL_H 
#define KERNEL_H 


/* Este é o cabeçalho mestre do núcleo. Ele inclui alguns outros arquivos 
* e define as principais constantes. 


#define _ 
#define | 
#define _ 


/* O que 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


POSIX_SOURCE 1 /* diz aos cabeçalhos para incluirem detalhes do POSIX */ 
MINIX 1 /* diz aos cabeçalhos para incluírem detalhes do MINIX */ 
SYSTEM 1 /* diz aos cabeçalhos que este é o núcleo */ 


segue é básico, todos os arquivos *.c files os obtém automaticamente. */ 
<minix/config.h> /* configuração global, DEVE ser o primeiro */ 

<ansi.h> /* estilo C: ANSI ou K&R, DEVE ser o segundo */ 
<sys/types.h> /* tipos de sistema gerais */ 

<minix/const.h> /* constantes específicas do MINIX */ 

<minix/type.h> /* tipos específicos do MINIX, por exemplo, mensagem */ 
<minix/ipc.h> /* sistema de tempo de execução do MINIX */ 

<timers.h> /* gerenciamento de temporizador cão de guarda */ 
<errno.h> /* códigos de retorno e números de erro */ 
<ibm/portio.h> /* E/S de dispositivo e interrupções alternadas */ 


/* Importante arquivos de cabeçalho do núcleo */ 


tinclude "config.h" /* configuração, DEVE ser o primeiro */ 

tinclude "const.h" /* constantes, DEVE ser o segundo */ 

ginclude "type.h" /* definições de tipo, DEVE ser o terceiro */ 

ginclude "proto.h" /* prototypes de função */ 

tinclude "glo.h” /* variáveis globais */ 

tinclude "ipc.h" /* constantes IPC */ 

/* &include "debug.h" */ /* depuração, DEVE ser o último cabeçalho do núcleo */ 


gendif /* KERNEL H */ 


HHHEHHHHHHHH H HHHH HHHH H+H H+ HH HHH H+H HHHH HHHH HHHH HHHH HHH HHHH H+H+HH+HH+H+HH+H+H+H+H+H+ 


kernel/config.h 


HEHEHEHEH HHHH HHHH HHHH HH HH HH HHH H+H HHHH HHHH ++ 


04700 
04701 
04702 
04703 
04704 
04705 
04706 
04707 
04708 
04709 


#ifndef CONFIG_H 
#define CONFIG_H 


/* Este arquivo define a configuração do núcleo. Ele permite configurar o tamanho de alguns 
* buffers do núcleo e ativar ou desativar código de depuração, recursos de sincronismo 
* e chamadas do núcleo individuais. 


* Alterações: 
+ 11 de julho de 2005 Criado. (Jorrit N. Herder) 


*/ 
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04710 
04711 
04712 
04713 
04714 
04715 
04716 
04717 
04718 
04719 
04720 
04721 
04722 
04723 
04724 
04725 
04726 
04727 
04728 
04729 
04730 
04731 
04732 
04733 
04734 
04735 
04736 
04737 
04738 
04739 
04740 
04741 
04742 
04743 
04744 
04745 
04746 
04747 
04748 
04749 
04750 
04751 
04752 
04753 
04754 
04755 
04756 
04757 
04758 
04759 
04760 
04761 
04762 
04763 
04764 
04765 
04766 
04767 
04768 
04769 


/* Em aplicativos incorporados e de percepção, nem todas as chamadas de núcleo podem 

* ser necessárias. Nesta seção, você pode especificar quais chamadas de núcleo são 

* necessárias e quais não são. O código das chamadas de núcleo desnecessárias não é 
incluído no binário do sistema, tornando-o menor. Se você não tiver certeza, é melhor 
manter todas as chamadas de núcleo ativadas. 


* 


e 


*/ 


#define USE FORK 1 /* cria um novo processo */ 

tdefine USE NEWMAP I /* configura um novo mapa de memória */ 
tdefine USE EXEC kh /* atualiza o processo após executar */ 
#define USE EXIT I /* limpeza após a saída do processo */ 

#define USE_TRACE 1 /* informações e monitoramento do processo */ 
#define USE_GETKSIG I /* recupera sinais do núcleo pendentes */ 
#define USE_ENDKSIG 1 /* finaliza sinais do núcleo pendentes */ 
ádefine USE KILL 1 /* envia um sinal para um processo */ 

tdefine USE SIGSEND 1 /* envia sinal estilo POSIX */ 

tdefine USE SIGRETURN 1 /* sys sigreturn(proc nr, ctxt_ptr, flags) */ 
gdefine USE ABORT 1 /* desliga o MINIX */ 

tdefine USE GETINFO 1 /* recupera uma cópia dos dados do núcleo */ 
ádefine USE TIMES 1 /* obtém informações de tempo do processo e do sistema */ 
tdefine USE SETALARM T /* programa um alarme síncrono */ 

#define USE_DEVIO 1 /* 1ê ou escreve em uma única porta de E/S */ 
define USE VDEVIO 1 /* processa vetor com requisições de E/S */ 
#define USE_SDEVIO 1 /* executa requisição de E/S em um buffer */ 
#define USE_IRQCTL 1 /* configura uma política de interrupção */ 
#define USE_SEGCTL 1 /* configura um segmento remoto */ 

tdefine USE PRIVCTL 1 /* controle de privilégios do sistema */ 
#define USE NICE 1 /* altera prioridade do escalonamento */ 
#define USE UMAP 1 /* mapeamento de endereço virtual em físico */ 
tdefine USE VIRCOPY 1 /* copia usando endereçamento virtual */ 
#define USE_VIRVCOPY 1 /* vetor com requisições de cópia virtual */ 
#define USE_PHYSCOPY 1 /* copia usando endereçamento físico */ 
#define USE_PHYSVCOPY 1 /* vetor com requisições de cópia física */ 
#define USE_MEMSET 1 /* escreve caractere em determinada área da memória */ 


/* Comprimento de nomes de programa armazenados na tabela de processos. Isso só é 
* usado para dumps de depuração que podem ser gerados com o servidorde informações. 
* O servidor PM mantém sua própria cópia do nome do programa. 

*/ 
#define P_NAME_LEN 8 


/* Os diagnósticos do núcleo são escritos em um buffer circular. Após cada mensagem, 
* um servidor do sistema é notificado e uma cópia do buffer pode ser recuperada para 
* exibir a mensagem. O tamanho dos buffers pode ser reduzido com segurança. 

*/ 
#define KMESS_BUF_SIZE 256 


/* Buffer para reunir aleatoriedade. Isso é usado para gerar um fluxo aleatório pelo 
* driver MEMORY, ao ler de /dev/random. 


define RANDOM ELEMENTS 32 


/* Esta seção contém definições de recursos importantes do sistema que são usados 
* pelos drivers de dispositivo. O número de elementos dos vetores é determinado pela 
* necessidade máxima de qualquer driver dado. O número de ganchos de interrupção pode 
* ser aumentado em sistemas com muitos drivers de dispositivo. 


*/ 
tdefine NR IRQ HOOKS 16 /* número de ganchos de interrupção */ 
tdefine VDEVIO BUF SIZE 64 /* máximo de elementos por requisição de VDEVIO */ 


tdefine VCOPY VEC SIZE 16 /* máximo de elementos por requisição de VCOPY */ 
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04770 
04771 /* Quantos bytes para a pilha do núcleo. Espaço alocado em mpx.s. */ 
04772 #define K STACK BYTES 1024 


04773 

04774 /* Esta seção permite ativar funcionalidade de depuração e sincronismo do núcleo. 
04775 * Para operação normal, todas as opções devem ser desativadas. 

04776 */ 


04777 #define DEBUG_SCHED_CHECK O /* verificação de sanidade das filas de escalonamento */ 
04778 #define DEBUG_LOCK_CHECK 0 /* verificação de sanidade de Tock() do núcleo */ 

04779 define DEBUG TIME LOCKS O /* mede o tempo gasto em bloqueios */ 

04780 

04781 #endif /* CONFIG H */ 

04782 


DO ssa oo O O O O HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO OO O O RO 
kernel/const.h 
HHHEHEHHHHHHH+ HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+H O O DO OO O O O 


04800 /* Macros e constantes gerais usadas pelo núcleo */ 
04801 #ifndef CONST_H 

04802 #define CONST_H 

04803 


04804 #include <ibm/interrupt.h> /* números de interrupção e vetores de hardware */ 
04805 #include <ibm/ports.h> /* endereços de porta e números mágicos */ 

04806 #include <ibm/bios.h> /* endereços da BIOS, tamanhos e números mágicos */ 
04807 #include <ibm/cpu.h> /* endereços da BIOS, tamanhos e números mágicos */ 
04808 #include <minix/config.h> 

04809 #include "config.h" 

04810 

04811 /* Para transformar um endereço no espaço do núcleo em um endereço físico. Isso é 
04812 * o mesmo que umap_local(proc_ptr, D, vir, sizeof(*vir)), mas menos dispendioso. 
04813 */ 

04814 #define vir2phys(vir) (kinfo.data base + (vir bytes) (vir)) 

04815 


04816 /* Mapeamento de um número de processo em uma id de estrutura de privilégio. */ 
04817 &define s nr to id(n) (NR TASKS + (n) + 1) 


04818 

04819 /* Transforma um ponteiro para um campo em uma estrutura em um ponteiro para a 

04820 * estrutura em si. Portanto, transforma "&struct ptr->field' de volta para 'struct ptr”. 
04821 */ 

04822 #define structof(type, field, ptr) \ 

04823 (Ctype *) (C(Cchar *) (ptr)) - offsetof(type, field))) 

04824 


04825 /* Constantes usadas em virtual copy(D. Os valores devem ser 0 e 1 respectivamente. */ 
04826 &define SRC 0 

04827 &define DST 1 

04828 

04829 /* Número de fontes aleatórias */ 

04830 #define RANDOM SOURCES 16 

04831 

04832 /* Constantes e macros para manipulação de mapa de bits. */ 

04833 define BITCHUNK BITS (sizeof(bitchunk t) * CHAR BIT) 

04834 #define BITMAP CHUNKSCnr bits) (((nr bits)+BITCHUNK BITS-1)/BITCHUNK BITS) 
04835 #define MAP CHUNK(map, bit) (map) [[(Cbit)/BITCHUNK BITS)] 

04836 #define CHUNK OFFSET(bit) ((bit)%BITCHUNK BITS)) 

04837 ádefine GET BITCmap,bit) ( MAP CHUNKCmap, bit) & (1 << CHUNK OFFSET(bit) ) 
04838 gdefine SET BIT(map,bit) ( MAP CHUNKC(map,bit) |= (1 << CHUNK OFFSETCbit) ) 
04839 define UNSET BITCmap,bit) ( MAP CHUNKCmap,bit) &= “(1 << CHUNK OFFSET(bit) ) 
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04840 
04841 
04842 
04843 
04844 
04845 
04846 
04847 
04848 
04849 
04850 
04851 
04852 
04853 
04854 
04855 
04856 
04857 
04858 
04859 
04860 
04861 
04862 
04863 
04864 
04865 
04866 
04867 
04868 
04869 
04870 
04871 
04872 
04873 
04874 
04875 


tdefine get sys bitC(map,bit) \ 

C MAP CHUNK (map. chunk,bit) & (1 << CHUNK_OFFSET (bit) ) 
#define set sys bit(map,bit) \ 

C MAP CHUNK(map.chunk, bit) |= (1 << CHUNK OFFSETCbit) ) 
tdefine unset sys bit(map,bit) \ 

(C MAP CHUNK (map. chunk,bit) &= “(1 << CHUNK OFFSET(bit) ) 
gdefine NR SYS CHUNKS BITMAP CHUNKS(NR SYS PROCS) 


/* Palavras da pilha do programa e máscaras. */ 


tdefine INIT PSW 0x0200 /* psw inicial */ 

tdefine INIT TASK PSW 0x1200 /* psw inicial para tarefas (com IOPL 1) */ 
tdefine TRACEBIT 0x0100 /* OU isso com psw em proc[] para monitoramento */ 
#define SETPSWCrp, new) /* permite apenas certos bits serem ativos */ \ 


(Crp)->p reg.psw = (rp)->p reg.psw & “0xCD5 | (new) & OxCD5) 
ádefine IF MASK 0x00000200 
ádefine IOPL MASK 0x003000 


/* Desativa/ativa interrupções de hardware. Os parâmetros de lock() e unlock() 
* são usados quando a depuração está ativada. Veja debug.h para obter mais informações. 
*/ 

tdefine lock(c, v) intr_disable(); 

#define unlock(c) intr_enable(); 


/* Tamanhos de tabelas de memória. O monitor de inicialização distingue três áreas 
* a saber: memória baixa, abaixo de 1M, 1M-16M e memória após 16M. Mais trechos são 
* necessários para o MINIX do DOS. 
*/ 

#define NR_MEMS 8 


#endif /* CONST_H */ 


HHHHHHHH+HH+H HH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


kernel/type.h 


HHHEHEHHHH+HHH+ HHHH HHH HH H+H H+ HHHH H+H HHHH HHHH H+H HHH HHHH HHH HHHH H+H+HH+HH+H+HH+H+H+H+H+H+ 


04900 
04901 
04902 
04903 
04904 
04905 
04906 
04907 
04908 
04909 
04910 
04911 
04912 
04913 
04914 


#ifndef TYPE_H 
#define TYPE_H 


typedef | PROTOTYPE( void task t, (void) ); 


/* Tabela de processos e tipos relacionados à propriedade do sistema. */ 


typedef int proc nr t; /* número de entrada da tabela de processos */ 

typedef short sys id t; /* índice de processo de sistema */ 

typedef struct { /* mapa de bits para índices do sistema */ 
bitchunk_t chunk[BITMAP_CHUNKS(NR_SYS_PROCS)]; 

} sys_map_t; 


struct boot_image { 
proc_nr_t proc_nr; * número de processo a usar */ 
task_t *initial_pc; /* função de início para tarefas */ 
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04915 
04916 
04917 
04918 
04919 
04920 
04921 
04922 
04923 
04924 
04925 
04926 
04927 
04928 
04929 
04930 
04931 
04932 
04933 
04934 
04935 
04936 
04937 
04938 
04939 
04940 
04941 
04942 
04943 
04944 
04945 
04946 
04947 
04948 
04949 
04950 
04951 
04952 
04953 
04954 
04955 
04956 
04957 
04958 
04959 
04960 
04961 
04962 
04963 
04964 
04965 
04966 
04967 
04968 
04969 
04970 
04971 
04972 
04973 
04974 


J; 


st 


J; 


int flags; 

unsigned char quantum; 

int priority; 

int stksize; 

short trap_mask; 

bitchunk_t ipc_to; 

long call mask; 

char proc name[P NAME LEN]; 


ruct memory 1 
phys clicks base; 
phys clicks size; 


P 


* flags de processo */ 

quantum (contador de tiques) */ 

* prioridade de escalonamento*/ 

* tamanho da pilha para tarefas */ 

traps de chamada de sistema permitidas */ 
envia proteção por máscara */ 

* proteção de chamada de sistema */ 

nome na tabela de processos */ 


* 


* 


$ * 


» 


+ ox 


/* endereço inicial do trecho */ 
* tamanho do trecho de memória */ 


/* O núcleo gera na saída mensagens de diagnóstico em um buffer circular. */ 


st 


}; 


st 


Js 


#i 
ty 


ruct kmessages { 
int km_next; 
int km_size; 


char km_buf[KMESS_BUF_SIZE]; 


ruct randomness { 
Struct { 
int r_next; 
int r_size; 


unsigned short r buf[RANDOM ELEMENTS]; /* buffer para informação aleatória */ 


} bin[ RANDOM SOURCES] ; 


f (CHIP == INTEL) 
pedef unsigned reg t; 


/* 


/* próximo índice a escrever */ 
/* tamanho corrente no buffer */ 
/* buffer para mensagens */ 


/* próximo índice a escrever */ 
/* número de elementos aleatórios */ 


registrador de máquina */ 


/* O layout do quadro da pilha é determinado pelo software, mas por eficiência 
* é organizado de modo que o código assembly o utilize da maneira mais simples possível. 
O modo protegido do 80286 e todos os modos reais usam o mesmo quadro, construído com 


* registradores de 16 bits. O modo real não possui troca de pilha automática; portanto, 


* pouco é perdido pelo fato de usar o quadro do 286 para ele. O quadro do 386 difere apenas 


St 
#i 


#e 


pelo fato de ter registradores de 32 bits e mais registradores de segmento. Os mesmos 


nomes são usados para os registradores maiores, para evitar diferenças no código. 


+ 


ruct stackframe s 1 
f WORD SIZE == 
ul6 t gs; 

ul6 t fs; 

ndif 

ul6 t es; 

ul6 t ds; 

reg t di; 

reg t si; 

reg t fp; 

reg t st; 

reg t bx; 

reg t dx; 

reg t cx; 

reg t retreg; 
reg t retadr; 
reg t pc; 

reg t cs; 

reg t psw; 


a a E N 


* proc ptr aponta para cá */ 


* último item extraído por save */ 


a 


*/ 
*/ 


di a cx não são acessados em C */ 
a ordem é para coincidir pusha/popa */ 


* bp 
* lacuna para outra cópia de sp */ 


*/ 


*/ 
*/ 
*/ 


* ax e acima são todos extraídos por save */ 


endereço de retorno para save() em código assembly */ 
^ último item extraído pela interrupção */ 


*/ 
*/ 
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04975 reg t sp; /* | */ 
04976 reg t ss; /* estes são extraídos pela CPU durante a interrupção */ 
04977 3; 

04978 

04979 struct segdesc s { /* descritor de segmento para modo protegido */ 


04980 ul6 t limit low; 
04981 ul6 t base low; 
04982 u8 t base middle; 


04983 u8 t access; /* |PIDL|LIX|EJRIA| */ 
04984 u8 t granularity; /* |G|X|O|AJLIMT| */ 
04985 u8 t base high; 

04986 3; 

04987 


04988 typedef unsigned long irq policy t; 
04989 typedef unsigned long irq id t; 


04990 

04991 typedef struct irq hook { 

04992 struct irq hook “next; /* próximo gancho no encadeamento */ 
04993 int (C“handler)(struct irq hook *); /* rotina de tratamento de interrupção */ 
04994 int irg; /* número de vetor de IRQ */ 

04995 int id; /* id desse gancho */ 

04996 int proc nr; /* NONE se não estiver em uso */ 
04997 irqid t notify id; /* id para retornar na interrupção */ 
04998 irq policy t policy; /* máscara de bits da política */ 
04999 } irqhook t; 

05000 

05001 typedef int (“irq handler t)(struct irq hook *); 

05002 

05003 gendif /* (CHIP == INTEL) */ 

05004 


05005 #if (CHIP == M68000) 

05006 /* os tipos específicos do M68000 ficam aqui. */ 
05007 #endif /* (CHIP == M68000) */ 

05008 

05009 #endif /* TYPE H */ 


DO ssa Do O O A O DO H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH O DD HHH O O DO OO O O DD O 
kernel/proto.h 
HHHEHEHHHHHH HH HHH HHHH HHHH HHHH HHHH HH H+H HH HHHH HHHH H+H O O DO O O O O O 


05100 /* Prototypes de função. */ 
05101 

05102 #ifndef PROTO_H 

05103 &define PROTO H 

05104 

05105 /* Declarações de estrutura. */ 
05106 struct proc; 

05107 struct timer; 

05108 

05109 /* clock.c */ 


05110 | PROTOTYPE( void clock task, (void) >; 
05111 | PROTOTYPE( void clock stop, (void) Jj; 
05112 _PROTOTYPEÇ clock t get uptime, (void) Ja 
05113 _PROTOTYPE(Ç unsigned long read clock, (void) J; 
05114 _PROTOTYPE(Ç void set timer, (struct timer *tp, clock_t t, tmr_func_t f) ); 
05115 _PROTOTYPE(Ç void reset timer, (struct timer *tp) Je 
05116 

05117 /* main.c */ 

05118 _PROTOTYPE(Ç void main, (void) J: 


05119 _PROTOTYPE(Ç void prepare shutdown, (int how) Ji 
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05120 
05121 
05122 
05123 
05124 
05125 
05126 
05127 
05128 
05129 
05130 
05131 
05132 
05133 
05134 
05135 
05136 
05137 
05138 
05139 
05140 
05141 
05142 
05143 
05144 
05145 
05146 
05147 
05148 
05149 
05150 
05151 
05152 
05153 
05154 
05155 
05156 
05157 
05158 
05159 
05160 
05161 
05162 
05163 
05164 
05165 
05166 
05167 
05168 
05169 
05170 
05171 
05172 
05173 
05174 
05175 
05176 
05177 
05178 
05179 


/* utility.c */ 


- PROTOTYPE( void kprintf, (const char *fmt, ...) 
- PROTOTYPE( void panic, ( CONST char *s, int n) 


/* proc.c */ 


- PROTOTYPE( int sys call, (int function, int src dest, message *m ptr) 
- PROTOTYPE( int lock notify, (int src, int dst) 
- PROTOTYPE( int lock send, (int dst, message *m ptr) 
- PROTOTYPE( void lock enqueue, (struct proc *rp) 
- PROTOTYPE( void lock dequeue, (struct proc *rp) 


/* start.c */ 
- PROTOTYPE( void 


/* system.c */ 


cstart, 


(U16 t cs, U16 t ds, U16 t mds, 
U16 t parmoff, U16 t parmsize) 


-PROTOTYPE( int get priv, (register struct proc *rc, int proc type) 
- PROTOTYPE( void send sig, (int proc nr, int sig nr) 

- PROTOTYPE( void cause sig, (int proc nr, int sig nr) 

- PROTOTYPE( void sys task, (void) 

- PROTOTYPE( void get randomness, (int source) 


- PROTOTYPE( int virtual copy, (struct vir addr *src, struct vir addr *dst, 


vir bytes bytes) 


tdefine numap lTocal(proc nr, vir addr, bytes) \ 
umap local (proc addr(proc nr), D, (vir addr), (bytes)) 

- PROTOTYPE( phys bytes umap local, (struct proc *rp, int seg, 

vir bytes vir addr, vir bytes bytes) 

- PROTOTYPE( phys bytes umap remote, (struct proc *rp, int seg, 

vir bytes vir addr, vir bytes bytes) 


- PROTOTYPE( phys bytes umap bios, (struct proc *rp, vir bytes vir addr, 


/* exception.c * 


vir bytes bytes) 


/ 


- PROTOTYPE( void exception, (unsigned vec nr) 


/* 18259.c */ 

- PROTOTYPE( void 
- PROTOTYPE( void 
- PROTOTYPE( void 


- PROTOTYPE( void 


/* klib*.s */ 


intr init, (Cint mine) 


intr_handle, (irq_hook_t *hook) 


put_irq_handler, (irq_hook_t *hook, int irq, 


irq_handler_t handler) 


rm_irq_handler, (Cirq_hook_t *hook) 


_PROTOTYPE( void int86, (void) 


- PROTOTYPE( void cp mess, (int src,phys_clicks src clicks,vir bytes src offset, 


- PROTOTYPE( void phys memset, (phys bytes source, unsigned long pattern, 


- PROTOTYPE( void 
- PROTOTYPE( void 
- PROTOTYPE( void 
- PROTOTYPE( void 
- PROTOTYPE( void 
-PROTOTYPE( void 


phys clicks dst clicks, vir bytes dst offset) 
- PROTOTYPE( void enable irg, Cirq hook t *hook) 
- PROTOTYPE( int disable irg, Cirq hook t *hook) 
- PROTOTYPE( ul6 t mem rdw, (U16 t segm, vir bytes offset) 

- PROTOTYPE( void phys copy, (phys bytes source, phys bytes dest, 
phys bytes count) 


phys bytes count) 
phys insb, (U16 t port, phys bytes buf, size t count) 
phys insw, (U16 t port, phys bytes buf, size_t count) 


phys outsb, (U16 t port, phys bytes buf, size_t count) ); 
phys outsw, (U16 t port, phys bytes buf, size_t count) ); 


reset, 
level0, 


(void) 
(void (*func) (void)) 


) 


J; 
j; 


) 


) 
) 
) 
) 


) . 


) 
) 
) 


) 
J 
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05180 | PROTOTYPE( void monitor, (void) já 
05181 | PROTOTYPE( void read tsc, (unsigned long *high, unsigned Tong *Tow) J; 
05182 _PROTOTYPE( unsigned long read cpu flags, (void) J3 
05183 

05184 /* mpx*.s */ 

05185 _PROTOTYPE(Ç void idle task, (void) J: 
05186 _PROTOTYPE(Ç void restart, (void) J; 
05187 


05188 /* Os seguintes nunca são chamados a partir da linguagem C (processos asm puros). */ 
05189 

05190 /* Rotinas de tratamento de exceção (modo real ou protegido), em ordem numérica. */ 
05191 void PROTOTYPE( int00, (void) ), | PROTOTYPE( divide error, (void) ); 

05192 void _PROTOTYPEÇ int01, (void) ), _PROTOTYPE( single step exception, (void) ); 
05193 void PROTOTYPE( int02, (void) ), | PROTOTYPEC nmi, (void) ); 

05194 void PROTOTYPE( int03, (void) ), _PROTOTYPE( breakpoint_exception, (void) ); 

05195 void PROTOTYPE( int04, (void) ), - PROTOTYPE( overflow, (void) ); 

05196 void PROTOTYPE(C int05, (void) ), _PROTOTYPE( bounds_check, (void) ); 

05197 void _PROTOTYPE(Ç( int06, (void) ), _PROTOTYPE(Ç inval_opcode, (void) ); 

05198 void _PROTOTYPE(Ç( int07, (void) ), - PROTOTYPE( copr_not_available, (void) ); 


05199 void _PROTOTYPE( double fault, (void) ); 

05200 void - PROTOTYPE( copr_seg_overrun, (void) ); 
05201 void _PROTOTYPE( inval_tss, (void) ); 

05202 void _PROTOTYPE( segment_not_present, (void) ); 
05203 void - PROTOTYPE( stack exception, (void) ); 
05204 void - PROTOTYPE( general protection, (void) ); 
05205 void - PROTOTYPE( page fault, (void) ); 

05206 void - PROTOTYPE( copr error, (void) ); 

05207 


05208 /* Rotinas de tratamento de interrupção de hardware. */ 
05209  PROTOTYPE( void hwint00, (void) ); 

05210 | PROTOTYPE( void hwint01, (void) ); 

05211 | PROTOTYPE( void hwint02, (void) ); 

05212 | PROTOTYPE( void hwint03, (void) ); 

05213 | PROTOTYPE( void hwint04, (void) ); 

05214 | PROTOTYPE( void hwintO5, (void) ); 

05215 | PROTOTYPE( void hwint06, (void) ); 

05216  PROTOTYPE( void hwintO7, (void) ); 

05217 | PROTOTYPE( void hwint08, (void) ); 

05218 | PROTOTYPE( void hwint09, (void) ); 

05219 | PROTOTYPE( void hwint10, (void) ); 

05220 | PROTOTYPE( void hwint11, (void) ); 

05221 | PROTOTYPE( void hwint12, (void) ) 
05222  PROTOTYPE( void hwint13, (void) ); 
05223 | PROTOTYPE( void hwintl4, (void) ) 
05224 | PROTOTYPE( void hwint15, (void) ) 
05225 

05226 /* Rotinas de tratamento de interrupção de software, em ordem numérica. */ 
05227 | PROTOTYPE( void trp, (void) ); 

05228 | PROTOTYPE( void s call, (void) ), - PROTOTYPE(C p s call, (void) ); 

05229 | PROTOTYPE( void TevelO call, (void) ); 


05230 

05231 /* protect.c */ 

05232 | PROTOTYPE( void prot init, (void) Jo 
05233 _PROTOTYPE( void init_codeseg, (struct segdesc s *segdp, phys bytes base, 
05234 vir_bytes size, int privilege) J; 
05235 _PROTOTYPE( void init dataseg, (struct segdesc_s *segdp, phys bytes base, 
05236 vir_bytes size, int privilege) J3 
05237 _PROTOTYPE( phys bytes seg2phys, (U16_t seg) J; 


05238 _PROTOTYPE(Ç void phys2seg, (ul6 t *seg, vir bytes *off, phys bytes phys)); 
05239 | PROTOTYPE( void enable iop, (struct proc *pp) ); 


ArênDicE B e O Cóbigo-FONTE DO MINIX 643 


05240 | PROTOTYPE( void alloc segments, (struct proc *rp) Jė 
05241 

05242 #endif /* PROTO_H */ 

05243 

05244 


DO spa Do O O O HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH H+H O O DO OO O O O DO 
kernel/glo.h 


HHHEHHHHH HHHH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH H+H H+H H+H HHHH HHHH HHHH HH+H+HH+H+H+H+H+H+ 


05300 #ifndef GLO_H 
05301 #define GLO_H 


05302 

05303 /* Variáveis globais usadas no núcleo. Este arquivo contém as declarações; 

05304 * o espaço de armazenamento para as variáveis é alocado em table.c, pois EXTERN é 
05305 * definida como extern, a não ser que a definição TABLE seja vista. Contamos com a 
05306 * inicialização padrão do compilador (0) para diversas variáveis globais. 

05307 */ 


05308 Hifdef TABLE 

05309 #undef EXTERN 

05310 #define EXTERN 

05311 #endif 

05312 

05313 #include <minix/config.h> 
05314 #include "config.h" 


05315 

05316 /* Variáveis relacionadas ao desligamento do MINIX. */ 

05317 EXTERN char kernel_exception; /* TRUE após exceções do sistema */ 

05318 EXTERN char shutdown_started; /* TRUE após desligamentos/reinicializações */ 
05319 

05320 /* Estruturas de informação do núcleo. Isto agrupa informações vitais do núcleo. */ 
05321 EXTERN phys bytes aout; /* endereço de cabeçalhos a.out */ 


05322 EXTERN struct kinfo kinfo; /* informações do núcleo para usuários */ 
05323 EXTERN struct machine machine; /* informações de máquina para usuários */ 
05324 EXTERN struct kmessages kmess; /* mensagens de diagnóstico no núcleo */ 
05325 EXTERN struct randomness krandom; /* reúne informações aleatórias do núcleo */ 


05326 
05327 /* Informações de escalonamento de processo e a contador de reentrada do núcleo. */ 
05328 EXTERN struct proc *prev_ptr; /* processo anteriormente em execução */ 


05329 EXTERN struct proc *proc_ptr; /* ponteiro para processo correntemente em execução */ 
05330 EXTERN struct proc *next_ptr;  /* próximo processo a executar após restart) */ 

05331 EXTERN struct proc *bill_ptr;  /* processo a ser cobrado por tiques de relógio */ 

05332 EXTERN char k_reenter; /* contador de reentrância (cont. de entrada -1) */ 

05333 EXTERN unsigned lost_ticks; /* tiques de relógio contados fora da tarefa de relógio */ 


05334 

05335 /* Variáveis relacionadas à interrupção. */ 

05336 EXTERN irq_hook_t irq hooks[NR IRQ HOOKS]; /* ganchos para uso geral */ 

05337 EXTERN irq hook t *irq handlers[NR IRQ VECTORS];/* lista de rotinas de tratamento de IRQ */ 
05338 EXTERN int irq actids[NR IRQ VECTORS]; /* ID de IRQ de bits ativos */ 

05339 EXTERN int irq use; /* mapa de todos os irq em uso */ 

05340 

05341 /* Diversos. */ 

05342 EXTERN reg t mon ss, mon sp; /* pilha do monitor de inicialização */ 

05343 EXTERN int mon return; /* verdadeiro se pudermos retornar ao monitor */ 
05344 

05345 /* As variáveis inicializadas em outras partes são apenas extern aqui. */ 

05346 extern struct boot image imagel]; /* processos da imagem do sistema */ 

05347 extern char *t stack[]; /* espaço de pilha de tarefas */ 

05348 extern struct segdesc s gdt[]; /* tabela descritora global */ 


05349 
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05350 EXTERN PROTOTYPE( void (*levelO func), (void) ); 
05351 

05352 #endif /* GLO H */ 

05353 

05354 

05355 

05356 

05357 


DO ssa Do DO O A Sa O HEHHE HHHH HHHH HHHH HHH HHHH H+H HH HHHH HHHH H+ O O O O OO O O O 
kernel/ipc.h 
HHHHHEHHHHHHH +H HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O DO O O O O 


05400 #ifndef IPC_H 
05401 #define IPC_H 


05402 

05403 /* Este arquivo de cabeçalho define constantes para comunicação entre processos do MINIX. 
05404 * Essas definições são usadas no arquivo proc.c. 

05405 */ 

05406 #include <minix/com.h> 

05407 


05408 /* Máscaras e flags para chamadas de sistema. */ 

05409 #define SYSCALL_FUNC 0x0F /* máscara para função de chamada de sistema */ 
05410 #define SYSCALL_FLAGS 0xF0 /* máscara para flags de chamada de sistema */ 
05411 #define NON BLOCKING 0x10 /* evita bloqueio, retorna erro */ 

05412 

05413 /* Números de chamada de sistema que são passados quando da captura no núcleo. Os 


05414 * números são cuidadosamente definidos para que possa ser facilmente vista (com base 
05415 * nos bits que estão ativos) quais verificações devem ser feitas em sys call. 
05416 */ 

05417 #define SEND 1 /* 0001: envio com bloqueio */ 

05418 #define RECEIVE 2 /* 0010: recepção com bloqueio */ 

05419 #define SENDREC 3 /* 0011: SEND + RECEIVE */ 

05420 #define NOTIFY 4 /* 0100: notificação sem bloqueio */ 

05421 #define ECHO 8 /*1 000: eco de uma mensagem */ 

05422 

05423 /* As máscaras de bits a seguir determinam quais verificações devem ser feitas. */ 
05424 define CHECK PTR 0x0B /* 1011 : valida buffer de mensagem */ 

05425 define CHECK DST 0x05 /* 0101 : valida destino da mensagem */ 

05426 #define CHECK_SRC 0x02 /* 0010 : valida origem da mensagem */ 

05427 


05428 #endif /* IPCH */ 


DO one oo o O O +H O RO DO HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH HHHH O DO DO O O O O 
kernel/proc.h 
AAA ++ 


05500 #ifndef PROC H 
05501 define PROC H 


05502 

05503 /* Aqui está a declaração da tabela de processos. Ela contém todos os dados de 

05504 * processo, incluindo registradores, flags, prioridade de escalonamento, mapa de 
05505 * memória, contabilidade, informações de passagem de mensagens (IPC) etc. 

05506 * 

05507 * Muitas rotinas em código assembly fazem referência a campos dela. Os deslocamentos 
05508 * nesses campos são definidos no arquivo include sconst.h do montador. Ao alterar 


05509 * struct proc, certifique-se de alterar sconst.h de acordo. 
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05510 
05511 
05512 
05513 
05514 
05515 
05516 
05517 
05518 
05519 
05520 
05521 
05522 
05523 
05524 
05525 
05526 
05527 
05528 
05529 
05530 
05531 
05532 
05533 
05534 
05535 
05536 
05537 
05538 
05539 
05540 
05541 
05542 
05543 
05544 
05545 
05546 
05547 
05548 
05549 
05550 
05551 
05552 
05553 
05554 
05555 
05556 
05557 
05558 
05559 
05560 
05561 
05562 
05563 
05564 
05565 
05566 
05567 
05568 
05569 


*/ 
tinclude 
tinclude 
tinclude 
tinclude 


struct p 
struct 
reg t 
struct 


proc n 
struct 


char p. 


char p_ 
char p | 
char p_ 
char p. 


struct mem map p memmap[NR LOCAL SEGS]; 


clock 
clock- 


struct 
struct 
struct 
messag 
proc_n 
proc_n 


sigset 


char p name[P NAME LEN]; 


3; 


/* Bits 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


_t p user time; 


<minix/com.h> 
"protect.h" 
"const.h" 
“priv.h" 


roc { 
stackframe_s p_reg; /* 
p_ldt_sel; /* 
segdesc s p Tdt[2+NR 


REMOTE SEGS]; 


registradores do processo salvos no quadro de pilha */ 
seletor em gdt com base e limite ldt */ 
/* CS, DS e segmentos remotos */ 


rtponr; 
priv *p priv; 
rts flags; 


= 


priority; 

max priority; 
ticks left; 
quantum size; /* 


== 


t psys time; 


proc *p nextready; 
proc *p caller q; 
proc *p q link; 

e *p messbuf; 

rtp getfrom; 

rtp sendto; 


_t p pending; 


o SAS N 


dos flags de tempo de execução. 


SLOT FREE 0x01 /* 
NO MAP 0x02 fa 
SENDING 0x04 no 
RECEIVING 0x08 pa 
SIGNALED 0x10 /* 
SIG PENDING 0x20 7 
P STOP 0x40 z” 
NO_PRIV 0x80 XE 


* nome do processo, 


* número desse processo (para acesso rápido) */ 


estrutura de privilégios do sistema */ 
SENDING, RECEIVING etc. */ 


* prioridade de escalonamento corrente */ 


prioridade de escalonamento máxima */ 


/* número de tiques de escalonamento restantes */ 


tamanho do quantum em tiques */ 


/* mapa de memória (T, D, S) */ 


* tempo do usuário em tiques */ 
* tempo do sistema em tiques */ 


* ponteiro para o próximo processo pronto */ 
* início da lista de processos que desejam enviar */ 
* vínculo para o próximo processo que deseja enviar */ 


ponteiro para buffer de mensagem passado */ 
de quem o processo deseja receber? */ 


* para quem o processo deseja enviar? */ 


* mapa de bits para sinais de núcleo pendentes */ 


incluindo NO */ 


q */ 


Um processo pode executar se p_rts_flags == 
a entrada do processo está livre */ 


* impede a execução de filho não mapeado */ 


processo bloqueado tentando ENVIAR */ 


* processo bloqueado tentando RECEBER */ 

* configurado quando chega o novo sinal do núcleo */ 

* não está pronto enquanto o sinal está sendo processado */ 
* configurado quando o processo está sendo monitorado */ 


impede a execução de processo de sistema bifurcado */ 


/* Prioridades de escalonamento para p_priority. Os valores devem começar em zero (prioridade 


* mais 


alta) e aumentar. 


As prioridades dos processos na imagem de inicialização 
* podem ser configuradas em table.c. 


IDLE deve ter uma fila para ela mesma, para evitar que 


* processos de usuário com baixa prioridade sejam executados em rodízio com IDLE. 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


/* Endereços mágicos da tabela de processos. 


NR SCHED QUEUES 16 /* 
TASK Q oo / 
MAX USER Q 0o 
USER Q FARA 
MIN USER Q 14º /* 
IDLE Q 15 /% 


* mais alta, 


DEVE ser igual à prioridade mínima + 1 */ 
usada para tarefas do núcleo */ 


* prioridade mais alta para processos de usuário */ 
* padrão (deve corresponder a nice 0) */ 


prioridade mínima para processos de usuário */ 
mais baixa, somente o processo IDLE fica aqui */ 


*/ 
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05570 
05571 
05572 
05573 
05574 
05575 
05576 
05577 
05578 
05579 
05580 
05581 
05582 
05583 
05584 
05585 
05586 
05587 
05588 
05589 
05590 
05591 
05592 
05593 
05594 
05595 
05596 
05597 
05598 


#define BEG PROC ADDR (&proc[0]) 
#define BEG USER ADDR (&proc[NR TASKS]) 
define END PROC ADDR (&proc[NR TASKS + NR PROCS]) 


tdefine NIL PROC (Cstruct proc *) 0) 

tdefine NIL SYS PROC (Cstruct proc *) 1) 

#define cproc addr(n) (&Cproc + NR TASKS) [(n)]) 
#define proc addr(n) Cpproc addr + NR TASKS) [(n)] 
tdefine proc nr(p) CCp)->p nr) 

#define isokprocn(n) (Cunsigned) ((n) + NR TASKS) < NR PROCS + NR TASKS) 
tdefine isemptyn(n) isemptyp(proc addr(n)) 

tdefine isemptyp(p) (Cp)->p rts flags == SLOT FREE) 
gdefine iskernelpCp) iskerneIn(Cp)->p nr) 

tdefine iskerneln(n) (Cn) < 0) 

gdefine isuserpC(p) isusern((p)->p nr) 

tdefine isusern(n) (Cn) >= 0) 


/* A tabela de processos e ponteiros para entradas da tabela de processos. Os ponteiros 
* permitem acesso mais rápido, pois agora uma entrada de processo pode ser encontrada pela 
* indexação do array pproc addr, enquanto o acesso a um elemento i exige uma 
* multiplicação com sizeof(struct proc) para determinar o endereço. 
*/ 
EXTERN struct proc proc[NR TASKS + NR_PROCS]; /* tabela de processos */ 
EXTERN struct proc *pproc addr[NR TASKS + NR PROCS]; 
EXTERN struct proc *rdy head[NR SCHED QUEUES]; /* ponteiros para inícios de lista prontos */ 
EXTERN struct proc *rdy tailT[NR SCHED QUEUES]; /* ponteiros para finais de lista prontos */ 


gendif /* PROC H */ 


HEHEHEHEH HEHH HHHH HHHH H+H H+ HH HHH H+H HHHH H+H HH HHHH H+H HHHH HHHH HHHH HH+H+H+H+H+H+H+H+H+ 


kernel/sconst.h 


HHHHHHHH HHHH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH ++ 


05600 
05601 
05602 
05603 
05604 
05605 
05606 
05607 
05608 
05609 
05610 
05611 
05612 
05613 
05614 
05615 
05616 
05617 
05618 
05619 
05620 
05621 
05622 
05623 
05624 


! Constantes diversas usadas em código de montador. 
Ww E _WORD_SIZE ! Tamanho da palavra de máquina. 


! Deslocamentos em struct proc. Eles DEVEM corresponder a proc.h. 


P_STACKBASE = 0 

GSREG = P STACKBASE 

FSREG = GSREG + 2 ! 386 introduz segmentos FS e GS 
ESREG = FSREG + 2 

DSREG = ESREG + 2 

DIREG = DSREG + 2 

SIREG = DIREG + W 

BPREG = SIREG + W 

STREG = BPREG + W ! Tacuna para outro SP 
BXREG = STREG + W 

DXREG = BXREG + W 

CXREG = DXREG + W 

AXREG = CXREG + W 

RETADR E AXREG + W ! endereço de retorno para chamada de save() 
PCREG = RETADR + W 

CSREG = PCREG + W 

PSWREG = CSREG + W 

SPREG = PSWREG + W 

SSREG = SPREG + W 

P STACKTOP = SSREG + W 

P LDT SEL = P STACKTOP 
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05625 PLDT = PDT SEL + W 
05626 
05627 Msize = 9 ! tamanho de uma mensagem em palavras de 32 bits 


DO one Do DO O a O O H HHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ +H O O O O O O O 
kernel/priv.h 
DO ssa Do o O O HHH HH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH H+ O DO OO O O O 


05700 #ifndef PRIV H 
05701 define PRIV H 


05702 

05703 /* Declaração da estrutura de privilégios do sistema. Ela define flags, máscaras de 
05704 * Chamada de sistema, um temporizador de alarme síncrono, privilégios de E/S, interrupções 
05705 * e notificações de hardware pendentes etc.Cada um dos processos de sistema recebe sua 
05706 * própria estrutura com propriedades, enquanto todos os processos de usuário compartilham 
05707 * uma única estrutura. Essa configuração proporciona uma separação clara entre os campos 
05708 * de processo comuns e privilegiados e é muito eficiente quanto ao espaço. 

05709 i 


05710 * Alterações: 

05711 * 01 de julho de 2005 Criado. (Jorrit N. Herder) 
05712 */ 

05713 #include <minix/com.h> 

05714 #include "protect.h" 

05715 #include "const.h" 

05716 #include "type.h" 


05717 

05718 struct priv { 

05719 proc_nr_t s_proc_nr; /* número do processo associado */ 

05720 sys_id_t s_id; /* índice dessa estrutura de sistema */ 

05721 short s_flags; /* PASSÍVEL DE PREEMPÇÃO, COBRANÇA etc. */ 
05722 

05723 short s_trap_mask; /* traps de chamada de sistema permitidas */ 
05724 sys_map_t s_ipc_from; /* chamadores dos quais se pode receber */ 
05725 sys_map_t s_ipc_to; /* processos de destino permitidos */ 

05726 long s_call_mask; /* chamadas de núcleo permitidas */ 

05727 

05728 sys_map_t s notify pending;  /* mapa de bits com notificações pendentes */ 
05729 irq_id_t s_int_pending; /* interrupções de hardware pendentes */ 
05730 sigset_t s_sig_pending; /* sinais pendentes */ 

05731 

05732 timer_t s_alarm_timer; /* temporizador de alarme síncrono */ 

05733 struct far_mem s_farmem[NR_REMOTE_SEGS]; /* mapa de memória remoto */ 
05734 reg_t *s_stack_guard; /* palavra de guarda de pilha para tarefas do kernel*/ 
05735- 5; 

05736 

05737 /* Palavra de guarda para pilhas de tarefa. */ 

05738 #define STACK GUARD (Creg t) (sizeof(reg t) == 2 ? OxBEEF : OxDEADBEEF)) 
05739 

05740 /* Bits para os flags de propriedade de sistema. */ 

05741 #define PREEMPTIBLE 0x01 /* tarefas do núcleo não sofrem preempção */ 
05742 #define BILLABLE 0x04 /* alguns processos não podem ser cobrados */ 
05743 define SYS PROC 0x10 /* os processos de sistema são privilegiados */ 
05744 define SENDREC BUSY 0x20 /* sendrec() em andamento */ 

05745 


05746 /* Endereços mágicos da tabela de estruturas de sistema. */ 
05747 #define BEG PRIV ADDR (&priv[0]) 

05748 ádefine END PRIV ADDR (&priv[NR SYS PROCS]) 

05749 
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05750 #define priv addr(i) Cppriv addr) [(Gi)] 


05751 #define priv idCrp) CCrp)->p priv->s id) 
05752 define privCrp) CCrp)->p priv) 
05753 


05754 #define id to nr(id) priv addr(id)->s proc nr 
05755 #define nr to id(nr) | privCproc addr(nr))->s id 


05756 

05757 /* A tabela de estruturas de sistema e ponteiros para entradas da tabela individuais. Os 
05758 * ponteiros permitem acesso mais rápido, pois uma entrada de processo pode ser encontrada 
05759 * pela indexação do array psys addr, enquanto acessar um elemento i exige uma 

05760 * multiplicação com sizeof(struct sys) para determinar o endereço. 

05761 */ 

05762 EXTERN struct priv priv[NR SYS PROCS]; /* tabela de propriedades do sistema */ 


05763 EXTERN struct priv *ppriv addr[NR SYS PROCS]; /* ponteiro de entrada direta */ 
05764 
05765 /* Todos os processos de usuário não privilegiados dividem a mesma estrutura de privilégios. 


05766 * Essa id deve ser fixa, pois é usada para verificar entradas da máscara de envio. 

05767 74 

05768 ádefine USER PRIV ID O 

05769 

05770 /* Certifica-se de que o sistema pode ser inicializado. A verificação de sanidade a 
05771 * seguir confere se a tabela de privilégios do sistema é grande o bastante para o número 
05772 * de processos na imagem de inicialização. 

05773 */ 


05774 #if (NR BOOT PROCS > NR_SYS_PROCS) 

05775 #error NR SYS PROCS must be larger than NR BOOT PROCS 
05776 #endif 

05777 

05778 #endif /* PRIVH */ 


DO sn Do O o a O O H HHH HHHH HHHH HHHH HHHH HH H+H HH HHHH O O DA H+ O O DO OO OD O O 
kernel/protect.h 
AAA ++ 


05800 /* Constantes do modo protegido. */ 

05801 

05802 /* Tamanhos de tabela. */ 

05803 ádefine GDT SIZE (FIRST LDT INDEX + NR TASKS + NR PROCS) 

05804 /* spec. and LDT's */ 

05805 define IDT SIZE (IRQ8 VECTOR + 8) /* apenas até o vetor mais alto */ 
05806  &define LDT SIZE (2 + NR REMOTE SEGS) /* CS, DS e segmentos remotos */ 
05807 

05808 /* Descritores globais fixos. de 1 a 7 são prescritos pela BIOS. */ 


05809 define GDT INDEX 1 /* descritor GDT */ 

05810 define IDT INDEX /* descritor IDT */ 

05811 &define DS INDEX 3 /* DS do núcleo */ 

05812 &define ES INDEX 4 /* ES do núcleo (386: 4 Gb de flag na inicialização) */ 
05813 &define SS INDEX 5 /* SS do núcleo (386: monitor SS na inicialização) */ 
05814 define CS INDEX 6 /* CS do núcleo */ 

05815 define MON CS INDEX 7 /* temp para BIOS (386: monitor CS na inicialização) */ 
05816 define TSS INDEX 8 /* TSS do núcleo */ 

05817 &define DS 286 INDEX 9 /* segmento de origem de rascunho de 16 bits */ 

05818 &define ES 286 INDEX 10 /* segmento de destino de rascunho de 16 bits */ 

05819 define A INDEX 11 /* 64K segmento de memória em A0000 */ 

05820 #define B INDEX 12 /* 64K segmento de memória em B0000 */ 

05821 #define C INDEX 13 /* 64K segmento de memória em C0000 */ 

05822 #define D INDEX 14 /* 64K segmento de memória em D0000 */ 

05823 &define FIRST LDT INDEX 15 /* o restante dos descritores são LDTs */ 


05824 
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05825 
05826 
05827 
05828 
05829 
05830 
05831 
05832 
05833 
05834 
05835 
05836 
05837 
05838 
05839 
05840 
05841 
05842 
05843 
05844 
05845 
05846 
05847 
05848 
05849 
05850 
05851 
05852 
05853 
05854 
05855 
05856 
05857 
05858 
05859 
05860 
05861 
05862 
05863 
05864 
05865 
05866 
05867 
05868 
05869 
05870 
05871 
05872 
05873 
05874 
05875 
05876 
05877 
05878 
05879 
05880 
05881 
05882 
05883 
05884 


E E E ERES 


#define GDT SELECTOR 0x08 
tdefine IDT SELECTOR 0x10 
tdefine DS SELECTOR 0x18 
tdefine ES SELECTOR 0x20 
#define FLAT_DS_SELECTOR 0x21 
#define SS_SELECTOR 0x28 
#define CS_SELECTOR 0x30 
#define MON_CS_SELECTOR 0x38 
#define TSS_SELECTOR 0x40 
#define DS_286_SELECTOR 0x49 
#define ES_286_SELECTOR 0x51 
/* Descritores locais fixos. */ 


#define 
#define 
#define 


CS_LDT_INDEX 0 
DS LDT INDEX 1 
EXTRA LDT INDEX 2 


/* Privilégios. */ 


tdefine 
tdefine 
tdefine 


INTR PRIVILEGE 0 
TASK PRIVILEGE 1 
USER PRIVILEGE 3 


* (GDT INDEX * DESC SIZE) ruim para asld */ 
* (IDT INDEX * DESC SIZE) */ 

* (DS INDEX * DESC SIZE) */ 

* (ES INDEX * DESC SIZE) */ 

* ES menos privilegiado */ 

t (SS INDEX * DESC SIZE) */ 

* (CS INDEX * DESC SIZE) */ 

* (MON CS INDEX * DESC SIZE) */ 

* (TSS INDEX * DESC SIZE) */ 

* (DS 286 INDEX*DESC SIZE+TASK PRIVILEGE) */ 
t (ES 286 INDEX*DESC SIZE+TASK PRIVILEGE) */ 


/* CS de processo */ 
/* DS=ES=FS=GS=SS de processo */ 
/* primeira das entradas de LDT extras */ 


/* núcleo e rotinas de tratamento de interrupção */ 
/* tarefas do núcleo */ 
/* servidores e processos de usuário */ 


/* constantes de hardware do 286. */ 


/* Números de vetor de exceção. 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


/* Bits 
tdefine 
tdefine 


BOUNDS VECTOR 5 
INVAL OP VECTOR 6 
COPROC NOT VECTOR 7 
DOUBLE FAULT VECTOR 8 
COPROC SEG VECTOR 9 
INVAL TSS VECTOR 10 


SEG NOT VECTOR 11 
STACK FAULT VECTOR 12 
PROTECTION VECTOR 13 
de seletor. */ 

TI 0x04 
RPL 0x03 


a I 


+N 


a verificação de limites falhou */ 
* código de operação inválido */ 
* co-processador não disponível */ 


* inundação de segmento de co-processador */ 
* TSS inválido */ 

* segmento não presente */ 

* exceção de pilha */ 

* proteção geral 


*/ 


/* indicador de tabela */ 
/* nível de privilégio do solicitante */ 


/* Deslocamentos da estrutura de descritor. 


tdefine 
tdefine 
tdefine 
tdefine 


DESC BASE 2 
DESC BASE MIDDLE 4 
DESC ACCESS 5 
DESC SIZE 8 


/* Tamanhos e mudanças de base 


tdefine 


/* Bits 
tdefine 
tdefine 
tdefine 
tdefine 


/* Bits 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


BASE MIDDLE SHIFT 16 
de byte de acesso e de 
PRESENT 0x80 
DPL 0x60 
DPL_SHIFT 5 
SEGMENT 0x10 
de byte de acesso. */ 

EXECUTABLE 0x08 
CONFORMING 0x04 
EXPAND_DOWN 0x04 
READABLE 0x02 
WRITEABLE 0x02 


poa 


e 


limite. */ 


a, 
* para base low */ 

* para base middle */ 

* para byte de acesso */ 

* sizeof (struct segdesc s) */ 


/* mudança de base --> base middle */ 


byte de tipo. */ 


/* 


PER 


configura para descritor presente */ 


* máscara de nível de privilégio de descritor */ 


* configura 


* configura 
* configura 
* configura 
* configura 
* configura 


para 


para 
para 
para 
para 
para 


descritores de tipo de segmento */ 


segmento executável */ 
conformar segmento se executável 
expandir segmento se !executável * 
segmento legível se executável */ 
segmento gravável se !executável 


*/ 


/ 


*/ 
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05885 
05886 
05887 
05888 
05889 
05890 
05891 
05892 
05893 
05894 
05895 
05896 
05897 
05898 
05899 
05900 
05901 
05902 
05903 
05904 
05905 
05906 
05907 
05908 
05909 
05910 
05911 
05912 
05913 
05914 
05915 
05916 
05917 
05918 
05919 
05920 
05921 
05922 
05923 


tdefine 
tdefine 


/* Tipos especiais de descritor. 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


TSS BUSY 
ACCESSED 


AVL 286 TSS 
LDT 
BUSY 286 TSS 


CALL 286 GATE 
TASK GATE 

INT 286 GATE 
TRAP 286 GATE 


0x02 /* configura se descritor de TSS estiver ocupado */ 
0x01 /* configura se for segmento acessado */ 


1 


3 
4 
5 
6 
7 


$F 


*/ 


TSS de 286 disponível*/ 
tabela de descritores local */ 


* configura de forma transparente para o software */ 
* não usado */ 


usado apenas pelo depurador */ 
porta de interrupção, usada por todos os vetores */ 


* não usado */ 


/* Constantes de hardware extras do 386. */ 


/* Números de vetor de exceção. */ 


#define 
#define 


PAGE_FAULT_VECTOR 
COPROC_ERR_VECTOR 


14 


16 /* erro de co-processador */ 


/* Deslocamentos da estrutura de descritor. */ 
6 /* para byte de granularidade */ 
/* para base_high */ 


#define 
#define 


DESC_GRANULARITY 
DESC_BASE_HIGH 


7 


/* Tamanhos e mudanças de base e limite. */ 
24 /* 
BYTE GRAN MAX O0xFFFFFL 

16 /* 
16 /* 
/* 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


/* Bits 
tdefine 


/* Byte 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


BASE HIGH SHIFT 
GRANULARITY SHIFT 
OFFSET HIGH SHIFT 
PAGE GRAN SHIFT 


de byte de tipo. 


12 


*/ 


DESC_386_BIT 0x08 /* Tipo 


de granularidade. 
GRANULAR 

DEFAULT 

BIG 

AVL 

LIMIT_HIGH 


*/ 

0x80 
0x40 
0x40 
0x10 
0x0F 


/* 


aa 


S 


mudança de base --> base_high */ 

/* tamanho máximo para segmento granularidade de byte */ 
mudança de elimit --> granularidade */ 

mudança de deslocamento (porta) --> offset_high */ 
mudança extra para limites granularidade de página */ 


do 386 são obtidos via ou lógico com isto */ 
LDTs e TASK_GATEs não precisam disso */ 


* configura para granularidade de 4K */ 
* configura p/ padrões de 32 bits (segmento executável) */ 


configura para "BIG" (segmento expandido para baixo) */ 
O para disponível */ 


* máscara para bits de limite altos */ 


HHHEHHHHHHHHH HH HH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HH O O O O DO OO O O O O 
kernel/table.c 
DO na Do o o O DS O O O HHHH HHHH HH HHHH HHHH HHHH HHHH HHHH H+ O O O SD DO OO O O O 


06000 
06001 
06002 
06003 
06004 
06005 
06006 
06007 
06008 
06009 
06010 
06011 
06012 
06013 
06014 


/* O arquivo objeto de "table.c” contém a maior parte dos dados do núcleo. As variáveis 
* declaradas nos arquivos *.h aparecem com EXTERN na frente, como em 


* EXTERN int x; 


* Normalmente, EXTERN é definida como extern, para que ao serem incluídas em outro 
* arquivo, nenhum espaço de armazenamento seja alocado. Se fosse apenas, 


int x; 


* então, incluir esse arquivo em vários arquivos-fonte faria com que 'x” fosse 


e 


* tx 


declarada várias vezes. Embora alguns ligadores aceitem isso, outros não aceitam; 
portanto, elas são declaradas como extern ao serem incluídas normalmente. Entretanto, 
deve ser realmente declarado em algum lugar. Isso é feito aqui, pela redefinição 


* de EXTERN como a string nula, para que a inclusão de todos os arquivos *.h em table.c 
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06015 
06016 
06017 
06018 
06019 
06020 
06021 
06022 
06023 
06024 
06025 
06026 
06027 
06028 
06029 
06030 
06031 
06032 
06033 
06034 
06035 
06036 
06037 
06038 
06039 
06040 
06041 
06042 
06043 
06044 
06045 
06046 
06047 
06048 
06049 
06050 
06051 
06052 
06053 
06054 
06055 
06056 
06057 
06058 
06059 
06060 
06061 
06062 
06063 
06064 
06065 
06066 
06067 
06068 
06069 
06070 
06071 
06072 
06073 
06074 


gere espaço de armazenamento para essas variáveis. 


* Diversas variáveis não poderiam ser declaradas como EXTERN, mas são declaradas como PUBLIC 
* ou PRIVATE. O motivo disso é que as variáveis extern não podem ter uma 

inicialização padrão. Se tais variáveis forem compartilhadas, elas também devem ser 
declaradas em um dos arquivos *.h sem a inicialização. Exemplos 

* incluem "boot image” (este arquivo), "idt' e 'gdt' (protect.c). 


Alterações: (Jorrit N. Herder) 

02 de agosto de 2005 configuração de privilégios e imagem de inicialização mínima 
* 17 de outubro de 2004 atualização anterior e comentários da tabela de tarefas 

* 01 de maio de 2004 estrutura alterada para imagem do sistema 


gdefine TABLE 


ginclude "kernel.h" 
tinclude "proc.h" 
tinclude "ipc.h” 
tinclude <minix/com.h> 
tinclude <ibm/int86.h> 


/* Define os tamanhos de pilha para as tarefas do núcleo incluídas na imagem do sistema. */ 
tdefine NO STACK 0 


tdefine SMALL STACK (128 * sizeof(char *)) 

tdefine IDL S SMALL STACK /* 3 intr, 3 temps, 4 db para Intel */ 
tdefine HRD S NO STACK /* tarefa fictícia, usa a pilha do núcleo */ 
tdefine TSK S SMALL STACK /* tarefa de sistema e relógio */ 


/* Espaço de pilha para todas as pilhas de tarefa. Declarado como (char *) para alinhar. */ 
#define TOT STACK SPACE (IDL S + HRDS + (2 * TSK S)) 
PUBLIC char *t stack[TOT STACK SPACE / sizeof(char *)]; 


/* Define flags para os vários tipos de processo. */ 


gdefine IDL F  (SYS PROC | PREEMPTIBLE | BILLABLE) /* tarefa IDLE */ 

#define TSK F  (SYS PROC) /* tarefas do núcleo */ 
gdefine SRV F  (SYS PROC | PREEMPTIBLE) /* serviços de sistema */ 
gdefine USR F (BILLABLE | PREEMPTIBLE) /* processos de usuário */ 


/* Define int. de chamada de sistema para os vários tipos de processo. Essas máscaras de 
* chamada determinam quais int. de chamada de sistema um processo pode fazer. 
*/ 

#define TSK T (1 << RECEIVE) /* relógio e sistema */ 

ádefine SRVT C0) /* serviços de sistema */ 

#define USR T ((1 << SENDREC) | (1 << ECHO)) /* processos de usuário */ 


/* As máscaras de envio determinam para quem os processos podem enviar mensagens ou 
* notificações. Os valores aqui são usados para os processos na imagem de inicialização. 
* Contamos com o código de inicialização em main() para casar o mapeamento de s nr para 
* id() para os processos na imagem de inicialização, para que a máscara de envio 
* definida aqui possa ser copiada diretamente em map[0] da máscara de envio atual. A 
* estrutura de privilégio O é compartilhada pelos processos de usuário. 
#/ 

#define s(n) (1 << s_nr_to_id(n)) 

#define SRVM C0) 

#define SYS_M (70) 

#define USR_M (s(PM_PROC_NR) | s(FS_PROC_NR) | s(RS_PROC_NR)) 

#define DRV_M (USR_M | s(SYSTEM) | s(CLOCK) | s(LOG_PROC_NR) | sCTTY PROC NRJ) 


/* Define as chamadas de núcleo que os processos podem fazer. Isso não parece muito 
* bom, mas precisamos definir os direitos de acesso de acordo com a chamada. 
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06075 
06076 
06077 
06078 
06079 
06080 
06081 
06082 
06083 
06084 
06085 
06086 
06087 
06088 
06089 
06090 
06091 
06092 
06093 
06094 
06095 
06096 
06097 
06098 
06099 
06100 
06101 
06102 
06103 
06104 
06105 
06106 
06107 
06108 
06109 
06110 
06111 
06112 
06113 
06114 
06115 
06116 
06117 
06118 
06119 
06120 
06121 


* Note que o servidor de reencarnação tem todos os bits ativos, pois ele deve 
* distribuir direitos para os serviços que inicia. 


*/ 
gdefine c(n) (1 << ((n)-KERNEL CALL)) 
#define RS € “0 
tdefine PM C “(c(SYS_DEVIO) | c(SYS SDEVIO) | cCSYS VDEVIO) N 


| CCSYS IRQCTL) | c(SYS INT86)) 

gdefine FS C — (c(SYS KILL) | cCSYS VIRCOPY) | C(SYS VIRVCOPY) | cCSYS UMAP) \ 
| CCSYS GETINFO) | c(SYS_EXIT) | CCSYS TIMES) | c(SYS SETALARM)) 

#define DRV_C (FSC | c(SYS SEGCTL) | c(SYS IRQCTL) | c(SYS INT86) \ 
| CCSYS DEVIO) | c(SYS VDEVIO) | cCSYS SDEVIO)) 

#define MEM C (DRV_C | c(SYS PHYSCOPY) | cCSYS PHYSVCOPY)) 


/* A tabela da imagem do sistema lista todos os programas que fazem parte da imagem de 
* inicialização. A ordem das entradas aqui PRECISA ser a ordem dos programas na imagem 
* de inicialização e todas as tarefas do núcleo devem vir primeiro. Cada entrada fornece 
* o número do processo, flags, o tamanho do quantum (q), a fila de escalonamento, as 
* int. permitidas, máscara de ipc e um nome para a tabela de processos. O contador de 
* programa inicial e o tamanho da pilha também são fornecidos para tarefas do núcleo. 
#/ 
PUBLIC struct boot_image image[] = { 
/* no. do processo, pc, flags, qs, fila, pilha, interrupções, ipcto, chamada, nome */ 


{ IDLE, idle task, IDL F, 8, IDLE Q, IDLS, 0, 0, O, “IDLE? F; 
{ CLOCK, clock task, TSK F, 64, TASK Q, TSK S, TSK T, 0, 0, "CLOCK" 3, 
{ SYSTEM, sys task, TSK F, 64, TASK Q, TSK S, TSK T, 0, 0, "SYSTEM"), 
{ HARDWARE, O, TSK F, 64, TASK Q, HRD_S, 0, 0, O, "KERNEL", 
{ PM PROC NR, O, SRV F, 32, 3, 0, SRV T, SRV_M, PMC, "pm" >, 
{ FS PROC NR, O, SRV. F, 32, 4, 0, SRV T, SRVM, FSC, "fs" >, 
{ RS PROC NR, O, SRVF, 4, 3, 0, SRV T, SYSM, RSC, "rs" >, 
{ TTY PROC NR, O, SRVF, 4, 1, 0, SRV T, SYSM, DRV_C, "tty" 3, 
{ MEM PROC NR, 0, SRVF, 4, 2, 0, SRV T, DRV. M, MEM C, "memory"+, 
{ LOG PROC NR, O, SRVF, 4, 2, 0, SRV T, SYSM, DRV_C, "log" 3, 
{ DRVR PROC NR, O, SRVF, 4, 2, 0, SRV T, SYS M, DRV C, "driver"), 
{ INIT PROC NR, O, USRF, 8, USERQ, 0, USR T, USRM, O, "init" F; 
Ta 


in 
a 


* Verifica o tamanho da tabela da imagem do sistema no momento da compilação. Também 
* verifica se o primeiro trecho da máscara ipc tem bits suficientes para acomodar os 
* processos na imagem. 
* Se for detectado um problema, o tamanho do array ‘fictício’ será negativo, 
* causando um erro de tempo de compilação. Note que nenhum espeço é realmente alocado, 
* pois ’dummy’ é declarado como extern. 
A 
extern int dummy[ (NR BOOT PROCS==sizeof (image) / 
sizeof(struct boot image))?1:-1]; 
extern int dummy[ (BITCHUNK BITS > NR BOOT PROCS - 1) ? 1 : -1]; 


HEHEHEH HH H+ HHH H+ HH H+ HH HHH HH HH HH HHHH H+H HH HH HHHH H+H HH ++ 


kernel/mpx.s 


HEHEHEHEHE HHHH HHH HHHH H+H HH HHH HHHH HH HHHH H+H HHH ++ 


06200 
06201 
06202 
06203 
06204 


# 
! Escolha entre as versões 8086 e 386 do código de inicialização do Minix. 


#include <minix/config.h> 
#if _WORD_SIZE == 
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06205 
06206 
06207 
06208 


#include "mpx88.s" 
#else 

#include "mpx386.s" 
#endif 


HEHEHEHEH HHHH HHHH HHH HH HH HH HHHH H+H HHHH HHHH HHHH HHHH HHH HHHH HHHH HH+H+HH+H+H+H+H+H+ 
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HEHEHEHEH HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


06300 
06301 
06302 
06303 
06304 
06305 
06306 
06307 
06308 
06309 
06310 
06311 
06312 
06313 
06314 
06315 
06316 
06317 
06318 
06319 
06320 
06321 
06322 
06323 
06324 
06325 
06326 
06327 
06328 
06329 
06330 
06331 
06332 
06333 
06334 
06335 
06336 
06337 
06338 
06339 
06340 
06341 
06342 
06343 
06344 
06345 
06346 
06347 
06348 
06349 


! Este arquivo, mpx386.s, é incluído por mpx.s quando o Minix é compilado para 
! CPUs Intel de 32 bits. O alternativo mpx88.s é compilado para CPUs de 16 bits. 


Este arquivo faz parte da camada inferior do núcleo do MINIX. (A outra parte 

é "proc.c".) A camada inferior processa a troca e o tratamento de mensagens. 

Além disso, ela contém o código de inicialização em assembly do Minix e as rotinas de 
tratamento de interrupção de 32 bits. Ela coopera com o código presente em "start.c" 
para configurar um bom ambiente para main. 


Toda transição para o núcleo passa por este arquivo. As transições para o 

núcleo podem ser aninhadas. A entrada inicial pode ser com uma chamada de sistema (isto é, 
enviar ou receber uma mensagem), uma exceção ou uma interrupção de hardware; as 
reentradas no núcleo só podem ser feitas por interrupções de hardware. A contagem de 
reentradas é mantida em "k reenter". Ela é importante para decidir se vai haver troca 
para a pilha do núcleo e para proteger o código de passagem de mensagens em "proc.c”. 


Para a interrupção de passagem de mensagens, a maior parte do estado da máquina é salva na 
tabela de processos. (Alguns dos registradores não precisam ser salvos.) Então, a pilha é 
trocada para "k stack" e as interrupções são reativadas. Finalmente, a rotina de tratamento 
de chamada de sistema (em C) é chamada. Quando ela retorna, as interrupções são desativadas 
novamente e o código entra na rotina de reinicialização, para finalizar as interrupções 
suspensas e executar o processo ou a tarefa cujo ponteiro está em "proc ptr”. 


As rotinas de interrupção de hardware fazem o mesmo, exceto (1) O estado inteiro deve 
ser salvo. (2) Existem rotinas de tratamento demais para fazer isso em linha; portanto, 
a rotina de salvamento é chamada. Alguns ciclos são economizados pela colocação do 
endereço da rotina de reinicialização apropriada para um retorno posterior. (3) Uma 
troca de pilha é evitada quando a pilha já foi trocada. (4) A controladora de interrupção 
(mestra) 8259 é reativada de forma centralizada em save()D. (5) Cada rotina de tratamento 
de interrupção mascara sua linha de interrupção usando a 8259 antes de ativar interrupções 
(outras, não mascaradas) e a desmascara após atender a interrupção. Isso limita o 

nível de aninhamento no número de linhas e protege a rotina de tratamento dela mesma. 


Para comunicação com o monitor de inicialização no momento da inicialização, alguns dados 
constantes são compilados no início do segmento de texto. Isso facilita 

a leitura dos dados no início do processo de inicialização, pois apenas o primeiro 
setor do arquivo precisa ser lido. 


Algum espaço de armazenamento de dados também é alocado no final deste arquivo. Esses 
dados estarão no início do segmento de dados do núcleo e serão lidos 
e modificados pelo monitor de inicialização antes que o núcleo inicie. 


seções 


.sect .text 
begtext: 
.sect .rom 
begrom: 
.sect .data 
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06350 begdata: 

06351 .sect .bss 

06352 begbss: 

06353 

06354 #include <minix/config.h> 
06355 &include <minix/const.h> 
06356 #include <minix/com.h> 
06357 #include <ibm/interrupt.h> 
06358 #include "const.h” 

06359 include "protect.h” 

06360 #include "sconst.h" 

06361 

06362 /* Selected 386 tss offsets. */ 
06363 define TSS3 S SPO 4 


06364 
06365 Funções exportadas 
06366 Nota: na linguagem assembly, a instrução .define aplicada a um nome de função 


! 
! 
06367 ! é vagamente equivalente a um prototype em código na linguagem C -- ela torna possível 
! 
! 


06368 vincular a uma entidade declarada no código assembly, mas não cria 
06369 a entidade. 
06370 


06371 .define _restart 

06372 .define save 

06373 

06374 .define divide error 

06375 .define single step exception 
06376 .define _nmi 

06377 .define breakpoint exception 
06378 .define overflow 

06379 .define | bounds check 

06380 .define inval opcode 

06381 .define copr not available 
06382 .define double fault 

06383 .define copr seg overrun 
06384 .define inval tss 

06385 .define segment not present 
06386 .define stack exception 
06387 .define general protection 
06388 .define page fault 

06389 .define copr error 

06390 

06391 .define _hwint00 ! rotinas de tratamento para interrupções de hardware 
06392 .define | hwint01 

06393 .define _hwint02 

06394 .define _hwint03 

06395 .define _hwint04 

06396 .define _hwint05 

06397 .define _hwint06 

06398 .define _hwint07 

06399 .define _hwint08 

06400 .define _hwint09 

06401 .define _hwint10 

06402 .define | hwintll 

06403 .define | hwint12 

06404 .define _hwint13 

06405 .define _hwint14 

06406 .define | hwint15 

06407 

06408 .define s call 

06409 .define ps call 
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06410 
06411 
06412 
06413 
06414 
06415 
06416 
06417 
06418 
06419 
06420 
06421 
06422 
06423 
06424 
06425 
06426 
06427 
06428 
06429 
06430 
06431 
06432 
06433 
06434 
06435 
06436 
06437 
06438 
06439 
06440 
06441 
06442 
06443 
06444 
06445 
06446 
06447 
06448 
06449 
06450 
06451 
06452 
06453 
06454 
06455 
06456 
06457 
06458 
06459 
06460 
06461 
06462 
06463 
06464 
06465 
06466 
06467 
06468 
06469 


.define Tevel0 call 


! Variáveis exportadas. 


.define begbss 


.define begdata 


«sect .text 


[RES SS egaso dE As A Da O qt O A O ppa Epa AO pn a a DO aee O pi ta ha * 


! este é o ponto de entrada do núcleo do MINIX 


MINIX 
imp 
. data? 
flags 
data? 
nop 


over flags: 


! Configura um quadro de pilha em C na pilha do monitor. (O monitor configura cs 


! corretamente. 
movzx 
push 
mov 
push 
push 
cmp 
jz 
inc 


noreti mov 


over_flags ! 
CLICK_SHIFT ! 


0x01FD 


pula os próximos bytes 
para o monitor: granularidade da memória 


flags do monitor de inicialização: 
ativa o modo 386, faz bss, faz a pilha, 
carrega no alto, não emenda, retornará, 
usa INT genérica, vetor de memória, 
novo retorno do código de inicialização 
byte extra para sincronizar o desmontador 


O descritor ss ainda referencia o segmento de dados do monitor.) 


esp, sp 
ebp 

ebp, esp 

esi 

edi 

4(ebp), O 
noret 

(mon return) 
C mon sp), esp 


! a pilha do monitor é de 16 bits 


! o vetor de retorno do monitor é 
! diferente de zero se o retorno é possível 


! salva ponteiro de pilha para retorno posterior 


! Copia a tabela de descritores global do monitor no espaço de endereço do núcleo e 
! troca para ele. Prot init() pode então atualizá-lo, com efeito imediato. 


sgdt 

mov 

mov 

mov 
copygdt: 
eseg movb 
movb 
inc 
inc 
loop 
mov 
and 
add 
mov 
Igdt 


! Localiza parâmetros de inicialização, configura reg. de segmento e pilha do núcleo. 
deslocamento dos parâmetros de inicialização 
comprimento dos parâmetros de inicialização 
endereço de cabeçalhos de a.out 


mov 
mov 
mov 
mov 
mov 
mov 


C gdt+GDT SELECTOR) 
esi, ( gdt+GDT SELECTOR+2) 


ebx, _gdt 
ecx, 8*8 
al, (esi) 
(ebx), al 
esi 

ebx 
copygdt 


eax, ( gdt+DS SELECTOR+2) 
eax, 0x00FFFFFF 

eax, _gdt 

Cgdt+GDT SELECTOR+2), eax 
C gdt+GDT SELECTOR) 


ebx, 8(ebp) ! 
edx, 12(ebp) ! 
eax, 16(ebp) ! 
(_aout), eax 

ax, ds ! 
es, ax 


dados do núcleo 


obtém a gdtr do monitor 

endereço absoluto da GTD 
endereço da GTD do núcleo 
copiando oito descritores 


base dos dados do núcleo 
somente 24 bits 

eax = vir2phys(gdt) 
configura base da GTD 
troca para a GTD do núcleo 


e ds 
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06470 mov fs, ax 

06471 mov gs, ax 

06472 mov ss, ax 

06473 mov esp, k stktop ! configura sp para apontar para o início do pilha do núcleo 
06474 

06475 ! Chama código de inicialização em C para configurar execução de main(). 

06476 push edx 

06477 push ebx 

06478 push SS SELECTOR 

06479 push DS SELECTOR 

06480 push CS SELECTOR 

06481 call _cstart ! cstart(cs, ds, mds, parmoff, parmlen) 

06482 add esp, 5*4 

06483 

06484 ! Recarrega gdtr, idtr e os reg. de segmento na tabela de descritores global configurada 
06485 ! por prot initQO. 

06486 

06487 Tgdt C gdt+GDT SELECTOR) 

06488 Tidt C(_gdt+IDT_SELECTOR) 

06489 

06490 jmpf CS_SELECTOR:csinit 

06491 csinit: 

06492 016 mov ax, DS SELECTOR 

06493 mov ds, ax 

06494 mov es, ax 

06495 mov fs, ax 

06496 mov gs, ax 

06497 mov ss, ax 

06498 016 mov ax, TSS SELECTOR ! nenhum outro TSS é usado 

06499 Ttr ax 

06500 push 0 ! configura flags com o estado bom conhecido 
06501 popf ! esp, limpa tarefa aninhada e ativa int 
06502 

06503 jmp “main ! mainQO 

06504 

06505 

06506. |%====================D=>>=D=>=D=>=DD=DD>>=2>>D=>=2=D==2=D==>>==>==>==>=>==2=================== * 
06507 !* rotinas de tratamento de interrupção x 
06508 !*rotinas de tratamento de interrupção para modo protegido de 32 bits do 386 * 
06509 !*=== 

06510 

06511 is 

06512 ! 

06513 ! 

06514 ! Note que esta é uma macro, ela apenas parece ser uma sub-rotina. 

06515 #define hwint master(irg) N 

06516 call save /* salva o estado do processo interrompido */;\ 
06517 push Cirq handlers+4*irg) /* irq handlers[irgl REN: 
06518 call “intr handle /* intr handle(irq handlers[ira]) */3N 
06519 pop ecx iN 
06520 cmp Cirq actids+4*irq), O /* interrupção ainda ativa? KEN: 
06521 jz of AN 
06522 inb INT_CTLMASK /* obtém máscara corrente */ N 
06523 orb al, [1<<irq] /* irq da máscara */ EN 
06524 outb INT_CTLMASK /* desativa o irq LN 
06525 O: movb al, END OF INT A 
06526 outb INT CTL /* reativa a 8259 mestra RAEN 
06527 ret /* reinicia (outro) processo */ 
06528 


06529 ! Cada um desses pontos de entrada é uma expansão da macro hwint master 
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06530 
06531 
06532 
06533 
06534 
06535 
06536 
06537 
06538 
06539 
06540 
06541 
06542 
06543 
06544 
06545 
06546 
06547 
06548 
06549 
06550 
06551 
06552 
06553 
06554 
06555 
06556 
06557 
06558 
06559 
06560 
06561 
06562 
06563 
06564 
06565 
06566 
06567 
06568 
06569 
06570 
06571 
06572 
06573 
06574 
06575 
06576 
06577 
06578 
06579 
06580 
06581 
06582 
06583 
06584 
06585 
06586 
06587 
06588 
06589 


.«align 16 
_hwint00: 
hwint_master (0) 


.align 16 
_hwint01: 
hwint master(1) 


.«align 16 
_hwint02: 
hwint master(2) 


.«align 16 
_hwint03: 
hwint master(3) 


.«align 16 
_hwint04: 
hwint master(4) 


.«align 16 
_hwint05: 
hwint master(5) 


.«align 16 
_hwint06: 
hwint master(6) 


.«align 16 
_hwint07: 
hwint_master (7) 


Rotina 


Rotina 


Rotina 


Rotina 


Rotina 


Rotina 


Rotina 


Rotina 


de 


de 


de 


de 


de 


de 


de 


de 


interrupção para irq 


interrupção para irq 


interrupção 


para irq 


interrupção para irq 


interrupção para irq 


interrupção para irq 


interrupção para irq 


interrupção para irq 


(relógio). 


(teclado) 


(cascata!) 


(segunda serial) 


(primeira serial) 


(winchester XT) 


(disquete) 


(impressora) 


! Note que esta é uma macro, ela apenas parece ser uma sub-rotina. 


aN 


* intr_handle(irq_handlers[irq]) */;\ 


interrupção ainda ativa? 


A 
EVAN 


* desativa o irq 


* reativa a 8259 mestra 
* reativa a 8259 escrava 


rr: 


#define hwint. slave(ira) NX 
call save 
push Cirq handlers+4*irg) 
call “intr handle 
pop ecx 
cmp Cirq actids+4*irq), 0 /* 
jz of 
inb INT2_CTLMASK 
orb al, [1<<[irq-8]] 
outb INT2_CTLMASK 
0: movb al, END OF INT 
outb INT_CTL 
outb INT2 CTL 
ret 


* reinicia (outro) processo 


! Cada um desses pontos de entrada é uma expansão da macro hwint slave 


.«align 16 
_hwint08: 
hwint_slave(8) 


.align 16 
_hwint09: 
hwint_slave(9) 


! Rotina de interrupção para irq 8 (relógio de tempo real) 


! Rotina de interrupção para irq 9 Cirq 2 redirecionado) 


/* salva o estado do processo interrompido */;N 
/* irq handlers[irgl] 
7 
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06590 .align 16 

06591  hwintlo: ! Rotina de interrupção para irq 10 

06592 hwint slave(10) 

06593 

06594 .«align 16 

06595  hwintll: ! Rotina de interrupção para irq 11 

06596 hwint slave(11) 

06597 

06598 .«align 16 

06599  hwintl2: ! Rotina de interrupção para irq 12 

06600 hwint slave(12) 

06601 

06602 .«align 16 

06603  hwint13: ! Rotina de interrupção para irq 13 (exceção de FPU) 
06604 hwint slave(13) 

06605 

06606 .«align 16 

06607 _hwint14: ! Rotina de interrupção para irq 14 (winchester AT) 
06608 hwint slave(14) 

06609 

06610 .«align 16 

06611  hwint15: ! Rotina de interrupção para irq 15 

06612 hwint slave(15) 

06613 

06614 | |f=======DDD=DDDDDDD5DD=DD=DD==2D=D>=2D>=D==D=D=2=D=2=>=>==>==>==2===>==>==>======================* 
06615 !* save E 
06616 !*============================== 
06617 ! Salva para modo protegido. 

06618 ! Isto é muito mais simples do que para o modo 8086, pois a pilha já aponta 
06619 ! para a tabela de processos ou já foi trocada para a pilha do núcleo. 

06620 

06621 .«align 16 

06622 save: 

06623 cld ! configura flag de direção com um valor conhecido 
06624 pushad ! salva registradores "gerais" 

06625 016 push ds ! salva ds 

06626 016 push es ! salva es 

06627 016 push fs ! salva fs 

06628 016 push gs ! salva gs 

06629 mov dx, ss ! ss é o segmento de dados do núcleo 

06630 mov ds, dx ! carrega o restante dos segmentos do núcleo 
06631 mov es, dx ! o núcleo não usa fs, gs 

06632 mov eax, esp ! prepara para retornar 

06633 inch ( k reenter) ! a partir de -1 se não estiver reentrando 
06634 jnz set restartl ! a pilha já é a pilha do núcleo 

06635 mov esp, k stktop 

06636 push _restart ! constrói end. de retorno p/ rotina de tratamento de int 
06637 xor ebp, ebp ! para rastreamento de pilha 

06638 jmp RETADR-P_STACKBASE (eax) 

06639 

06640 .align 4 

06641 set restartl: 

06642 push restartl 

06643 jmp RETADR-P STACKBASE (eax) 

06644 

06645 !* 

06646 !* -s call * 
06647 | |k======D=DDD=DDDDDDD5DD=DD=DD=DDD=DD=2>=DD==D==D=D=2=>=>==>==2==2==>==D==>===========>===========* 
06648 .«align 16 


06649 | s call: 
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ps call 
cld ! configura flag de direção com um valor conhecido 
sub esp, 6*4 ! pula RETADR, eax, ecx, edx, ebx, est 
push ebp ! a pilha já aponta para a tabela de proc 
push esi 
push edi 


016 push ds 
016 push es 
016 push fs 
016 push gs 


mov dx, ss 

mov ds, dx 

mov es, dx 

inch (k reenter) 

mov esi, esp ! presume P STACKBASE == 
mov esp, k stktop 


xor ebp, ebp para rastreamento de pilha 
fim do salvamento em Tinha 


agora, configura parâmetros para sys cali() 


push ebx ponteiro para mensagem do usuário 
push ecx SEND/RECEIVE/BOTH 
call “sys call sys call(function, src dest, m ptr) 


processo que fez a chamada está em proc ptr 


l 
l 
! 
! 
push eax ! orig/dest 
! 
! 
! 
! sys call DEVE PRESERVAR si 


mov AXREG(esi), eax 
! Entra no código para reiniciar proc/tarefa em execução. 


_restart: 


! Reinicia o process corrente ou o próximo processo, se estiver configurado. 


cmp Cnext ptr), O ! testa se outro processo está pronto p/ executar 
jz of 
mov eax, (next ptr) 
mov Cproc ptr), eax ! escalona execução do novo processo 
mov Cnext ptr), O 
o: mov esp, C proc ptr) presumirá P_STACKBASE == 


Vidt P LDT SEL(esp) 
lea eax, P_STACKTOP (esp) 
mov (_tss+TSS3_S_SP0), eax 


ativa descritores de segmento do processo 
prepara a próxima interrupção 


restarti: 

decb (_k_reenter) 

016 pop gs 

016 pop fs 

016 pop es 

016 pop ds 
popad 
add esp, 4 ! pula end de retorno 
iretd ! continua o processo 


“divide error: 
push DIVIDE VECTOR 
jmp exception 


para salvar o estado na tabela de processos 
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06710 

06711 | single step exception: 

06712 push DEBUG VECTOR 
06713 jmp exception 

06714 

06715 _nmi: 

06716 push NMI VECTOR 

06717 jmp exception 

06718 

06719 | breakpoint exception: 

06720 push BREAKPOINT VECTOR 
06721 jmp exception 

06722 

06723  overflow: 

06724 push OVERFLOW VECTOR 
06725 jmp exception 

06726 

06727 | bounds check: 

06728 push BOUNDS VECTOR 
06729 jmp exception 

06730 

06731 | inval opcode: 

06732 push INVAL OP VECTOR 
06733 jmp exception 

06734 

06735 ' copr not available: 

06736 push COPROC NOT VECTOR 
06737 jmp exception 

06738 

06739 double fault: 

06740 push DOUBLE FAULT VECTOR 
06741 jmp errexception 
06742 

06743 | copr seg overrun: 

06744 push COPROC SEG VECTOR 
06745 jmp exception 

06746 

06747 _inval_tss: 

06748 push INVAL TSS VECTOR 
06749 jmp errexception 
06750 

06751 | segment not present: 

06752 push SEG NOT VECTOR 
06753 jmp errexception 
06754 

06755 | stack exception: 

06756 push STACK FAULT VECTOR 
06757 jmp errexception 
06758 

06759 ' general protection: 

06760 push PROTECTION VECTOR 
06761 jmp errexception 
06762 

06763 page fault: 

06764 push PAGE FAULT VECTOR 
06765 jmp errexception 
06766 

06767 | copr error: 

06768 push COPROC ERR VECTOR 


06769 jmp exception 
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06770 
06771 
06772 
06773 
06774 
06775 
06776 
06777 
06778 
06779 
06780 
06781 
06782 
06783 
06784 
06785 
06786 
06787 
06788 
06789 
06790 
06791 
06792 
06793 
06794 
06795 
06796 
06797 
06798 
06799 
06800 
06801 
06802 
06803 
06804 
06805 
06806 
06807 
06808 
06809 
06810 
06811 
06812 
06813 
06814 
06815 
06816 
06817 
06818 
06819 
06820 
06821 
06822 
06823 
06824 
06825 
06826 
06827 
06828 
06829 


! Isto é chamado para todas as exceções que não extraem um código de erro. 


.«align 16 
exception: 
sseg mov (trap errno), O ! limpa trap errno 
sseg pop (ex number) 
jmp exceptionl 


! Isto é chamado para todas as exceções que extraem um código de erro. 


.«align 16 
errexception: 
sseg pop (ex number) 
sseg pop (trap errno) 
exceptionl: ! Comum para todas as exceções. 
push eax ! eax é registrador de rascunho 
mov eax, 0+4(esp) ! eip antigo 
sseg mov Cold eip), eax 
movzx eax, 4+4(esp) ! cs antigo 
sseg mov (Cold cs), eax 
mov eax, 8+4(esp) ! eflags antigo 
sseg mov Cold eflags), eax 
pop eax 
call save 


push Cold eflags) 
push (Cold cs) 
push Cold eip) 


push (trap errno) 
push (ex number) 
call “exception ! (ex number, trap errno, old eip, 


! old cs, old eflags) 


ret 
[ED === T[/][/[[]/][//[[ >= === + 
E Tevel0O call i 
E TERE Ee re. 
_level0_call: 

call save 

jmp (_level0_func) 
| É E e TT —————— 
li data * 
[È corr pe e e eean 
.sect .rom ! Antes da tabela de string, por favor! 

.data? 0x526F ! esta deve ser a primeira entrada de dados (no. mágico) 
.sect .bss 
k stack: 

.space K STACK BYTES ! pilha do núcleo 
k stktop: ! início da pilha do núcleo 


.comm ex number, 4 
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06830 
06831 
06832 
06833 


.comm trap errno, 4 
.comm oldeip, 4 
.comm oldecs, 4 
.comm old eflags, 4 
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06900 
06901 
06902 
06903 
06904 
06905 
06906 
06907 
06908 
06909 
06910 
06911 
06912 
06913 
06914 
06915 
06916 
06917 
06918 
06919 
06920 
06921 
06922 
06923 
06924 
06925 
06926 
06927 
06928 


06929 
06930 
06931 
06932 
06933 
06934 
06935 
06936 
06937 
06938 
06939 
06940 
06941 
06942 
06943 
06944 
06945 
06946 
06947 
06948 
06949 


/* Este arquivo contém o código de inicialização em C do Minix em processadores Intel. 
* Ele coopera com mpx.s para configurar um bom ambiente para main). 


Este código é executado no modo real para um núcleo de 16 bits e deve trocar 

* para modo protegido em um 286. 

* Para um núcleo de 32 bits este já executa no modo protegido, mas os seletores 
ainda são aqueles dados pela BIOS com interrupções desativadas; portanto, os 
descritores precisam ser recarregados e os descritores de interrupção criados. 


#include "kernel.h" 
#include "protect.h" 
#include "proc.h" 

#include <stdlib.h> 
#include <string.h> 


FORWARD _PROTOTYPE(Ç char *get value, ( CONST char *params, _CONST char *key)); 


/¥======= 
i cstart j 
* === Y / 

PUBLIC void cstart(cs, ds, mds, parmoff, parmsize) 

U16 t cs, ds; /* código e segmento de dados do núcleo */ 

U16 t mds; /* segmento de dados do monitor */ 

U16 t parmoff, parmsize; /* desloc. e comprimento dos parâm. de inicialização */ 
{ 


/* Realiza inicializações do sistema antes de chamar main). A maioria das configurações 


* é determinada com a ajuda das strings de ambiente passadas pelo carregador do MINIX. 


*/ 

char params[128*sizeof(char *)]; /* parâmetros do monitor de inicialização 
#/ 

register char *value; /* valor no par chave=valor */ 


extern int etext, end; 


/* Decide se o modo é protegido; 386 ou acima implica no modo protegido. 
* Isto deve ser feito primeiro, pois é necessário, por exemplo, para seg2phys O. 
* Para máquinas 286, não podemos optar ainda pelo modo protegido. Isso é 
* feito a seguir. 
*/ 
#if _WORD_SIZE != 2 
machine.protected = 1; 
#endif 


/* Registra onde estão o núcleo e o monitor. */ 
kinfo.code base = seg2phys(cs); 


kinfo.code size = (phys bytes) &etext; /* tamanho do segmento de código */ 
kinfo.data base = seg2phys(ds); 
kinfo.data size = (phys bytes) &end; /* tamanho do segmento de dados */ 


/* Inicializa descritores de modo protegido. */ 
prot initO; 
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06950 
06951 
06952 
06953 
06954 
06955 
06956 
06957 
06958 
06959 
06960 
06961 
06962 
06963 
06964 
06965 
06966 
06967 
06968 
06969 
06970 
06971 
06972 
06973 
06974 
06975 
06976 
06977 
06978 
06979 
06980 
06981 
06982 
06983 
06984 
06985 
06986 
06987 
06988 
06989 
06990 
06991 


06993 
06994 
06995 
06996 
06997 
06998 
06999 
07000 
07001 
07002 
07003 
07004 
07005 
07006 
07007 
07008 
07009 


# 


# 


P 


{ 


/* Copia os parâmetros de inicialização no buffer local. */ 
kinfo.params base = seg2phys(mds) + parmoff; 

kinfo.params size = MIN(parmsize,sizeof(params)-2); 

phys copy(kinfo.params base, vir2phys(params), kinfo.params size); 


/* Registra informações diversas para servidores em espaço de usuário. */ 
kinfo.nr procs = NR PROCS; 

kinfo.nr tasks = NR TASKS; 

strncpy(kinfo.release, OS RELEASE, sizeof(kinfo.release)); 


kinfo.release[sizeof(kinfo.release)-1] = “NO”; 
strncpy(kinfo.version, OS VERSION, sizeof(kinfo.version)); 
kinfo.version[sizeof(kinfo.version)-1] = “NO”; 


kinfo.proc addr = (vir bytes) proc; 
kinfo.kmem base = vir2phys(0); 
kinfo.kmem size = (phys bytes) &end; 


/* Processador? 86, 186, 286, 386, 

* Decide se o modo é protegido para máquinas antigas. 
machine.processor=atoi (get value(params, "processor")); 
if WORD SIZE == 
machine.protected = machine.processor >= 286; 
endif 
if (! machine.protected) mon return = 0; 


/* XT, AT or MCA bus? */ 
value = get value(params, "bus"); 
if (value == NIL PTR || strcmplvalue, "at") == 0) { 


machine.pc at = TRUE; /* hardware compatível com PC-AT */ 


} else if (strcmp(value, "mca") == 0) { 
machine.pc at = machine.ps mca = TRUE; /* PS/2 com micro canal */ 


} 

/* Tipo de VDU: */ 

value = get value(params, "video"); /* unidade de vídeo EGA ou VGA */ 
if (strcmp(value, "ega") == 0) machine.vdu ega = TRUE; 

if (strcmp(value, "vga") == 0) machine.vdu vga = machine.vdu ega = TRUE; 


/* Retorna para o código assembly para trocar para o modo protegido (se for 286), 
* recarrega seletores e chama main). 


RIVATE char *get value(params, name) 
CONST char *params; 
CONST char *name; /* chave a pesquisar */ 


/* parâmetros do monitor de inicialização */ 


/* Obtém valor de ambiente - versão do núcleo a partir de getenv para evitar a configuração 


* do array de ambiente normal. 
*/ 

register CONST char *namep; 
register char *envp; 


for (envp = (char *) params; *envp != 0;) É 
for (namep = name; *namep != O && *namep == *envp; namep++, envp++) 
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if (*namep == "NO" && *envp == 
while (*envp++ != 0) 


=") return(envp + 1); 


} 
return(NIL_PTR); 


HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH H+H+HH+HH+H+H+H+H+H+H+H+H+ 
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07100 
07101 
07102 
07103 
07104 
07105 
07106 
07107 
07108 
07109 
07110 
07111 
07112 
07113 
07114 
07115 
07116 
07117 
07118 
07119 
07120 
07121 
07122 
07123 
07124 
07125 
07126 
07127 
07128 
07129 
07130 
07131 
07132 
07133 
07134 
07135 
07136 
07137 
07138 
07139 
07140 
07141 
07142 
07143 
07144 


/* 


* 


3 


* 


Este arquivo contém o programa principal do MINIX, assim como seu código de 
desativação/parada. A rotina main inicializa o sistema e inicia as atividades 
configurando a tabela de processos, os vetores de interrupção e o escalonamento de 
cada tarefa a ser executada para se inicializar. A rotina shutdowun() faz o oposto 
e desliga o MINIX. 
As entradas neste arquivo são: 

main: programa principal do MINIX 

prepare shutdown: prepara para desativar(parar) o MINIX 
Alterações: 

24 de novembro de 2004 mainQ) simplificado com imagem de sistema (Jorrit N. Herder) 

20 de agosto de 2004 novos prepare shutdoun() e shutdown) (Jorrit N. Herder) 


+ 


tinclude "kernel.h” 
tinclude <signal.h> 
ginclude <string.h> 
#include <unistd.h> 
#include <a.out.h> 
#include <minix/callnr.h> 
#include <minix/com.h> 
#include "proc.h" 


/* Declarações de prototype para funções PRIVATE. */ 
FORWARD _PROTOTYPE( void announce, (void)); 
FORWARD | PROTOTYPE( void shutdown, (timer t *tp)); 


PUBLIC void main) 


{ 


/* Inicia as atividades. */ 


struct boot_image *ip; /* ponteiro da imagem de inicialização */ 
register struct proc *rp; /* ponteiro de processo */ 

register struct priv *sp; /* ponteiro da estrutura de privilégios */ 
register int i, S; 

int hdrindex; /* índice para array de cabeçalhos de a.out */ 


phys_clicks text_base; 

vir_clicks text_clicks, data_clicks; 

reg_t ktsb; /* base da pilha de tarefas do núcleo */ 
struct exec e_hdr; /* para uma cópia de um cabeçalho de a.out */ 


/* Inicializa a controladora de interrupção. */ 
intr_init(1); 
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07145 
07146 
07147 
07148 
07149 
07150 
07151 
07152 
07153 
07154 
07155 
07156 
07157 
07158 
07159 
07160 
07161 
07162 
07163 
07164 
07165 
07166 
07167 
07168 
07169 
07170 
07171 
07172 
07173 
07174 
07175 
07176 
07177 
07178 
07179 
07180 
07181 
07182 
07183 
07184 
07185 
07186 
07187 
07188 
07189 
07190 
07191 
07192 
07193 
07194 
07195 
07196 
07197 
07198 
07199 
07200 
07201 
07202 
07203 
07204 


/* Limpa a tabela de processos. Anuncia cada entrada como vazia e configura mapeamentos 
* para macros proc addr() e proc nr(). Faz o mesmo para a tabela com 
* estruturas de privilégio para os processos de sistema. 


*/ 
for (rp = BEG_PROC_ADDR, i = -NR_TASKS; rp < END_PROC_ADDR; ++rp, ++i) { 
rp->p_rts_flags = SLOT_FREE; /* inicializa entrada livre */ 
rp->p nr = ï; /* número de proc a partir do ptr */ 
(pproc addr + NR TASKS) [i] = rp; /* ptr de proc a partir do número */ 
} 
for (sp = BEG_PRIV_ADDR, i = 0; sp < END_PRIV_ADDR; ++sp, ++i) { 
sp->s_proc_nr = NONE; /* inicializa como livre */ 
sp->s id = i; /* índice de estrutura priv */ 
ppriv addr[il] = sp; /* ptr priv a partir do número */ 
} 


/* Configura entrada da tabela de proc para tarefas e servidores. As pilhas das 
* tarefas do núcleo são inicializadas com um array no espaço de dados. As pilhas 
* dos servidores foram adicionadas no segmento de dados pelo monitor; portanto, 
* o ponteiro de pilha é configurado no final do segmento de dados. Todos os 
* processos ficam na memória inferior no 8086. No 386, apenas o núcleo 
* fica na memória inferior, o restante é carregado na memória estendida. 


/* Pilhas de tarefa. */ 
ktsb = (reg t) t stack; 


for (i=0; i < NR BOOT PROCS; ++i) { 


ip = &image[i]; /* atributos do processo */ 

rp = proc addr(ip->proc nr); /* obtém ponteiro do processo */ 
rp->p max priority = ip->priority; /* prioridade de execução max */ 
rp->p priority = ip->priority; /* prioridade corrente */ 

rp->p quantum size = ip->quantum; /* tamanho do quantum em tiques */ 
rp->p ticks left = ip->quantum; /* crédito corrente */ 


strncpy(rp->p name, ip->proc name, P NAME LEN);/* configura nome do processo */ 
(void) get privCrp, Cip->flags & SYS PROC)); /* atribui estrutura */ 


privCrp)->s flags = ip->flags; /* flags de processo */ 
privCrp)->s trap mask = ip->trap mask; /* interrupções permitidas */ 
privC(rp)->s call mask = ip->call mask; /* máscara de chamada do núcleo */ 
priv(rp)->s ipc to.chunk[0] = ip->ipc to; /* restringe alvos */ 
if (iskerneln(proc nrCrp))) É /* parte do núcleo? */ 

if Cip->stksize > 0) 1 /* o tamanho da pilha de HARDWARE é O */ 


rp->p priv->s stack guard = (reg t *) ktsb; 
*rp->p priv->s stack guard = STACK GUARD; 


} 
ktsb += ip->stksize; /* aponta para extremidade superior da pilha */ 
rp->p reg.sp = ktsb; /* ptr de pilha inicial desta tarefa */ 


text base = kinfo.code base >> CLICK SHIFT; 
/* processos que estão no núcleo */ 
hdrindex = 0; /* todos usam o primeiro cabeçalho de a.out */ 
+ else { 
hdrindex = 1 + i-NR TASKS; /* servidores, drivers, INIT */ 
; 


/* O carregador de inicialização criou um array dos cabeçalhos de a.out no 
* endereço absoluto "aout”. Obtém um elemento para e hdr. 
*/ 
phys copy(aout + hdrindex * A MINHDR, vir2phys(&e hdr), 
Cphys bytes) A MINHDR); 
/* Converte endereços em clicks e constrói mapa de memória do processo */ 
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07205 
07206 
07207 
07208 
07209 
07210 
07211 
07212 
07213 
07214 
07215 
07216 
07217 
07218 
07219 
07220 
07221 
07222 
07223 
07224 
07225 
07226 
07227 
07228 
07229 
07230 
07231 
07232 
07233 
07234 
07235 
07236 
07237 
07238 
07239 
07240 
07241 
07242 
07243 
07244 
07245 
07246 
07247 
07248 
07249 
07250 
07251 
07252 
07253 


07255 
07256 
07257 
07258 
07259 
07260 
07261 
07262 
07263 
07264 


text base = e hdr.a syms >> CLICK SHIFT; 

text clicks = (e hdr.a text + CLICK SIZE-1) >> CLICK SHIFT; 

if (!(e hdr.a flags & A SEPJ) text clicks = 0; /* I&D comum */ 

data clicks = (e hdr.a total + CLICK SIZE-1) >> CLICK SHIFT; 

rp->p memmap[T] .mem phys = text base; 

rp->p memmap[T] .mem Ten = text clicks; 

rp->p memmap[D] .mem phys text base + text clicks; 

rp->p memmap[D] .mem Ten = data clicks; 

rp->p memmap[S] .mem phys text base + text clicks + data clicks; 

rp->p memmap[S].mem vir = data clicks; /* vazio - a pilha está nos dados */ 


/* Configura valores de registrador iniciais. A palavra de status do processador 
* para tarefas é diferente da de outros processos, pois as tarefas podem 

* acessar E/S; isso não é permitido para processos menos privilegiados 

*/ 

rp->p_reg.pc = (reg t) ip->initial pc; 

rp->p reg.psw = (iskernelp(rp)) ? INIT TASK PSW : INIT PSW; 


/* Inicializa o ponteiro de pilha do servidor. Leva uma palavra para baixo 
* para dar a crtso.s algo para usar como "argc". 


*/ 
if (isusern(proc nrCrp))) { /* processo em espaço de usuário? */ 
rp->p reg.sp = (rp->p memmap[S] .mem vir + 
rp->p memmap[S] .mem Ten) << CLICK SHIFT; 
rp->p reg.sp -= sizeof(reg t); 
} 


/* Configura como pronto. A tarefa HARDWARE nunca está pronta. */ 
if Crp->p nr != HARDWARE) { 


rp->p_rts_flags = 0; /* executável se não houver flags */ 

lock enqueue(rp); /* adiciona nas filas do escalonador */ 
+ else { 

rp->p rts flags = NO MAP; /* impede a execução */ 


} 


/* Os segmentos de código e de dados devem ser alocados no modo protegido. */ 
alloc segments(rp); 


} 


/* Definitivamente não estamos desligando. */ 
shutdown_started = 0; 


/* O MINIX está pronto. Todos processos da imagem de inicialização estão na fila de 
* prontos. Retorna para o código assembly para começar a executar o processo corrente. 


*/ 


bill_ptr = proc_addr (IDLE); /* ele precisa apontar para algum lugar */ 
announce(); /* imprime identificação do MINIX */ 
restart(); 
} 
J * === 
i announce x 
Xon a) 
PRIVATE void announce(void) 
{ 


/* Exibe a identificação de inicialização do MINIX. */ 

kprintf("MINIX %s.%s." 
"Copyright 2006, Vrije Universiteit, Amsterdam, The Netherlands\n", 
OS RELEASE, OS VERSION); 
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07265 
07266 
07267 
07268 


07270 
07271 
07272 
07273 
07274 
07275 
07276 
07277 
07278 
07279 
07280 
07281 
07282 
07283 
07284 
07285 
07286 
07287 
07288 
07289 
07290 
07291 
07292 
07293 
07294 
07295 
07296 
07297 
07298 
07299 
07300 
07301 
07302 
07303 
07304 
07305 
07306 
07307 
07308 
07309 
07310 
07311 
07312 
07313 
07314 
07315 
07316 
07317 
07318 


07320 
07321 
07322 
07323 
07324 


/* Modo real ou modo protegido de 16/32 bits? */ 
kprintf("Executing in %s mode. Ann", 


machine.protected ? "32-bit protected" : "real"); 

} 

A O 
É prepare shutdown hi 
* === / 

PUBLIC void prepare_shutdown (how) 

int how; 

{ 


/* Esta função prepara para desligar o MINIX. */ 
static timer_t shutdown_timer; 
register struct proc *rp; 
message m; 


/* Exibe dumps de depuração em caso de pânico. Certifica-se de que a tarefa TTY ainda 
* está disponível para manipulá-los. Isso é feito com a ajuda de um envio sem bloqueio. 
* Contamos com TTY para chamar sys_abort() quando tiver terminado os dumps. 

*/ 
if (how == RBT_PANIC) { 
m.m_type = PANIC_DUMPS; 
if (nb_send(TTY_PROC_NR,&m)==0K) /* não bloqueia se TTY não estiver pronto */ 
return; /* aguarda sys abort() de TTY */ 


/* Envia um sinal para todos os processos de sistema que ainda estão ativos para 
* informá-los que o núcleo do MINIX está sendo desligado. Uma sequência de 
* desligamento correta deve ser implementada por um servidor em espaço de usuário. 
* Esse mecanismo é útil como backup no caso de pânico no sistema, para que os processos 
* de sistema ainda possam executar seu código de desligamento, por exemplo, para 
* sincronizar o FS ou permitir que o TTY troque para o primeiro console. 
* 
kprintf('Sending SIGKSTOP to system processes .. An"); 
for (rp=BEG PROC ADDR; rp<END PROC ADDR; rp++) { 
if Clisemptyp(lrp) && CprivCrp)->s flags & SYS PROC) && !iskernelpCrp)) 
send sig(proc nr(rp), SIGKSTOP); 
} 


/* Estamos desligando. Os diagnósticos podem ter comportamento diferente agora. */ 
shutdown_started = 1; 


/* Notifica os processos de sistema sobre o desligamento a ocorrer e permite que eles 
* sejam escalonados, configurando um temporizador cão de guarda que chama shutdown). 
* O argumento do temporizador passa o status do desligamento. 

*/ 

kprintfC'MINIX will now be shut down ...\n"); 

tmr arg(&shutdown timer)->ta int = how; 


/* Continua após 1 segundo, para dar aos processos uma chance de serem 
* escalonados para fazer o desligamento funcionar. 


* 


set timer (&shutdown timer, get uptime) + HZ, shutdown); 


PRIVATE void shutdown(tp) 
timer t *tp; 


668 SISTEMAS OPERACIONAIS 


07325 4 

07326 /* Esta função é chamada a partir de prepare shutdown ou de stop sequence para desligar 
07327 * o MINIX. O modo de desligamento está no argumento: RBT HALT (retorna para o 

07328 * monitor), RBT MONITOR (executa código dado), RBT RESET (reconfiguração incondicional). 
07329 RÁ 

07330 int how = tmr arg(tp)->ta int; 

07331 ul6 t magic; 

07332 

07333 /* Agora, mascara todas as interrupções, incluindo o relógio, e pára o relógio. */ 


07334 outb(INT CTLMASK, “0); 
07335 clock stop(); 


07336 

07337 if (mon return && how != RBT RESET) 1 

07338 /* Reinicializa as controladoras de interrupção com os padrões da BIOS. */ 

07339 intr init(0); 

07340 outb (INT CTLMASK, 0); 

07341 outb(INT2 CTLMASK, 0); 

07342 

07343 /* Retorna p/ o monitor de inicialização. Configura programa, se ainda não foi feito. */ 
07344 if (Chow != RBT MONITOR) phys copy(vir2phys("'D, kinfo.params base, 1); 

07345 TevelOCmonitor); 

07346 

07347 

07348 /* Reconfigura o sistema pulando para o endereços de reconfiguração (modo real) ou 
07349 * forçando um desligamento do processador (modo protegido). Primeiro, interrompe o teste 
07350 * de memória da BIOS, ativando um flag de reconfiguração condicional. 

07351 */ 


07352 magic = STOP_MEM_CHECK; 

07353 phys_copy(vir2phys(&magic), SOFT RESET FLAG ADDR, SOFT RESET FLAG SIZE); 
07354 TevelOCreset); 

07355 + 


DO soa oo o O a O HH HHHH HH HHHH HHHH HHHH HH HHHH HHHH O DD O O O O DO DO O O DS 
kernel/proc.c 
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07400 /* Este arquivo contém basicamente todo o tratamento de processo e mensagem. 


07401 * Junto com "mpx.s", ele forma a camada de nível mais baixo do núcleo do MINIX. 

07402 * Existe apenas um ponto de entrada a partir de fora: 

07403 E 

07404 * sys call: uma chamada de sistema; isto é, o núcleo é interrompido com uma INT 
07405 * 

07406 * Assim como vários pontos de entrada usados do nível de interrupção e tarefa: 

07407 * 

07408 *  Tock notify: notifica um processo a respeito de um evento do sistema 

07409 *  Tock send: envia uma mensagem para um processo 

07410 * — Tock enqueue: coloca um processo em uma das filas de escalonamento 

07411 * Tock dequeue: remove um processo das filas de escalonamento 

07412 k 

07413 * Alterações: 

07414 E 19 de agosto de 2005 código do escalonador reescrito (Jorrit N. Herder) 

07415 z 25 de julho de 2005 tratamento de chamada de sistema reescrito (Jorrit N. Herder) 
07416 * 26 de maio de 2005 funções de passagem de mensagem reescritas (Jorrit N. Herder) 
07417 * May 24, 2005 nova chamada de sistema de notificação (Jorrit N. Herder) 

07418 * 28 de outubro de 2004 chamadas de envio e recepção sem bloqueio (Jorrit N. Herder) 


07419 de 
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07420 
07421 
07422 
07423 
07424 
07425 
07426 
07427 
07428 
07429 
07430 
07431 
07432 
07433 
07434 
07435 
07436 
07437 
07438 
07439 
07440 
07441 
07442 
07443 
07444 
07445 
07446 
07447 
07448 
07449 
07450 
07451 
07452 
07453 
07454 
07455 
07456 
07457 
07458 
07459 
07460 
07461 
07462 
07463 
07464 
07465 
07466 
07467 
07468 
07469 
07470 
07471 
07472 
07473 
07474 
07475 
07476 


* O código aqui é fundamental para fazer tudo funcionar e é importante para o 


* desempenho global do sistema. Grande parte do código trata com 
* manipulação de lista. Para tornar isso fácil de entender e rápido de executar 
* são usados ponteiros de ponteiro por todo o código. Os ponteiros de ponteiro evitam 


* exceções do início ou fim de uma lista encadeada. 


* node t *queue, *new node; // assume isso como variáveis globais 

* node t **xpp = &queue; // obtém ponteiro de ponteiro para início da fila 
* while (*xpp != NULL) // encontra o último ponteiro da lista encadeada 
* xpp = &(*xpp)->next; // obtém ponteiro para próximo ponteiro 

* *xpp = new node; // agora, substitui o fim (o ponteiro NULL) 


* new. 


node->next = NULL; // e marca o novo fim da lista 


* Por exemplo, ao adicionar um novo nó no final da lista, normalmente 
* se faz uma exceção para uma lista vazia e pesquisa o final da lista em busca de 
* listas não vazias. Conforme mostrado acima, isso não é exigido com ponteiros de ponteiro. 


*/ 


#include 
#include 
#include 
#include 


<minix/com.h> 


<minix/calinr.h> 


"kernel.h" 
"proc.h" 


/* Funções de escalonamento e passagem de mensagem. As funções estão disponíveis para 


* outras partes do núcleo através de lock ...()D. A trava desativa temporariamente 


* as interrupções para evitar condições de corrida. 


*/ 


FORWARD | PROTOTYPEC int 


message 


FORWARD | PROTOTYPE( int 


message 


FORWARD | PROTOTYPEC int 


mini send, (struct proc *caller ptr, int dst, 

*m ptr, unsigned flags) ); 

mini receive, (struct proc *caller ptr, int src, 
*m ptr, unsigned flags) ); 

mini notify, (struct proc *caller ptr, int dst) ); 


FORWARD | PROTOTYPE( void enqueue, (struct proc *rp) ); 

FORWARD | PROTOTYPE( void dequeue, (struct proc *rp) ); 

FORWARD | PROTOTYPE( void sched, (struct proc *rp, int “queue, int *front) ); 
FORWARD | PROTOTYPE( void pick proc, (void) ); 


tdefine 


BuildMess(m ptr, 
(m ptr)->m source = (src); 


(m ptr)->m type 


Cm ptr)->NOTIFY TIMESTAMP = get uptime); 


switch (src) { 
case HARDWARE: 


Cm ptr)- 
priv(dst ptr)->s int pending = 0; 


break; 
case SYSTEM: 


Cm ptr)- 
priv(dst ptr)->s sig pending = 0; 


break; 


} 


src, dst ptr) \ 


= NOTIFY FROMCsrc); 


>NOTIFY ARG = priv(dst ptr)->s int pending; 


>NOTIFY ARG = priv(dst ptr)->s sig pending; 


PA A RR O E 


tdefine CopyMess(s,sp,sm,dp,dm) N 
cp mess(s, (sp)->p memmap[D] .mem phys, N 
(vir bytes)sm, (dp)->p memmap[D] .mem phys, (vir bytes)dm) 
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PUBLIC in 


t sys call(call nr, src dst, m ptr) 
int call nr; /* número e flags da chamada de sistema */ 
int src dst; /* src para recebimento ou dst para envio */ 
message *m ptr; /* ponteiro para msg no processador chamador */ 
{ 


/* As chamadas de sistema são feitas interrompendo-se o núcleo com uma instrução INT. 
p ç 
* A interrupção é capturada e sys call() é chamada para enviar ou receber uma mensagem 
* (ou ambos). O processo que fez a chamada é sempre dado por "proc ptr”. 
*/ 


register struct proc *caller_ptr = proc_ptr; /* obtém ptr do processo que fez a chamada */ 


int function = call_nr & SYSCALL_FUNC; /* obtém função de chamada de sistema */ 
unsigned flags = call_nr & SYSCALL_FLAGS; /* obtém flags */ 

int mask entry; /* bit para verificar máscara de envio */ 
int result; /* o resultado da chamada de sistema */ 
vir clicks vlo, vhi; /* clicks virtuais contendo a mensagem a ser enviada */ 


/* Verifica se o processo tem privilégios para a chamada solicitada. As chamadas para o 
* núcleo só podem ser SENDREC, pois as tarefas sempre respondem e não podem bloquear 
* se o processo que fez a chamada não executar receive(). 
*/ 
if (! (priv(caller_ptr)->s_trap_mask & (1 << function)) || 
Ciskerneln(src_dst) && function != SENDREC 
&& function != RECEIVE)) { 
kprintf("sys_call: trap %d not allowed, caller %d, src dst %d\n", 
function, proc nr(caller ptr), src dst); 
return (ECALLDENTED) ; /* interrupção negada pela máscara ou pelo núcleo */ 


} 


/* Exige um processo de origem e/ou destino válido, a não ser que ecoe. */ 
if (! (Cisokprocn(src dst) || src dst == ANY || function == ECHO)) { 
kprintfC'sys call: invalid src dst, src_dst %d, caller %d\n", 
src dst, proc nr(caller ptr)); 
return (EBADSRCDST) ; /* número de processo inválido */ 
} 


/* Se a chamada envolve um buffer de mensagem, isto é, para SEND, RECEIVE, SENDREC, 
* ou ECHO, verifica o ponteiro de mensagem. Essa verificação permite que uma mensagem 
* esteja em qualquer lugar nos dados, na pilha ou na lacuna. Ela terá que se tornar mais 
* elaborada para máquinas que não têm a lacuna mapeada. 
*/ 
if (function & CHECK_PTR) { 
vlo = (vir bytes) m_ptr >> CLICK SHIFT; 
vhi = ((vir bytes) m ptr + MESS SIZE - 1) >> CLICK SHIFT; 
if (vlo < caller ptr->p memmap[D] .mem vir || vlo > vhi || 
vhi >= caller ptr->p memmap[S] .mem vir + 
caller ptr->p memmap[S] .mem Ten) { 
kprintfC'sys call: invalid message pointer, trap %d, caller %d\n", 
function, proc nr(caller ptr)); 
return(EFAULT); /* ponteiro de mensagem inválido */ 


} 


/* Se a chamada é para enviar para um processo, isto é, para SEND, SENDREC ou NOTIFY, 
* verifica se o processo que fez a chamada pode enviar para o destino dados e 
* se o destino ainda está ativo. 
*/ 

if (function & CHECK_DST) { 
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if (4 get sys bit(priv(caller ptr)->s ipc to, nr to id(src dst))) { 
kprintfC'sys call: ipc mask denied %d sending to %d\n", 
proc nr(caller ptr), src dst); 
return (ECALLDENTED) ; /* chamada negada pela máscara de ipc */ 


} 


if Cisemptyn(src dst) && !shutdown_started) { 
kprintf("sys_call: dead dest; %d, %d, %d\n", 
function, proc nr(caller ptr), src dst); 
return (EDEADDST) ; /* não pode enviar para o morto */ 


/* Agora, verifica se a chamada é conhecida e tenta executar a requisição. As únicas 
* chamadas de sistema que existem no MINIX são mensagens de envio e recepção. 
* — SENDREC: combina SEND e RECEIVE em uma única chamada de sistema 
* — SEND: o remetente é bloqueado até que sua mensagem tenha sido enviada 
* — RECEIVE: o receptor é bloqueado até que uma mensagem aceitável tenha chegado 
* — NOTIFY: chamada sem bloqueio; envia notificação ou marca como pendente 
* — ECHO: chamada sem bloqueio; ecoa a mensagem diretamente 
*/ 

switch(function) { 

case SENDREC: 

/* Um flag é ativado para que as notificações não possam interromper SENDREC. */ 
priv(caller_ptr)->s_flags |= SENDREC_BUSY; 
/* falha */ 
case SEND: 
result = mini_send(caller_ptr, src_dst, m_ptr, flags); 
if (function == SEND || result != OK) { 
break; /* pronto ou SEND falhou */ 
} /* falha para SENDREC */ 
case RECEIVE: 
if (function == RECEIVE) 
priv(caller ptr)->s flags &= “SENDREC BUSY; 
result = mini receive(caller ptr, src dst, m ptr, flags); 
break; 
case NOTIFY: 
result = mini notify(caller ptr, src dst); 
break; 

case ECHO: 

CopyMess(caller ptr->p nr, caller ptr, m ptr, caller ptr, m ptr); 

result = OK; 

break; 
default: 

result = EBADCALL; /* chamada de sistema ilegal */ 
} 


/* Agora, retorna o resultado da chamada de sistema para o processo que fez a chamada. */ 
return(result); 


F 
/* === 
* mini_send id 
dED==D==D>D>=D>=>>=>>=>=>==>>=>>>>>>>=>>>>>>>>=>>>>>=>>>>=>>>=>>>>>=>=>>=>>>=>=>=>=>>=>=>=>==>==* / 
PRIVATE int mini send(caller ptr, dst, m ptr, flags) 
register struct proc *caller ptr; /* quem está tentando enviar uma mensagem? */ 
int dst; /* para quem a mensagem está sendo enviada? */ 


message “*m ptr; 
unsigned flags; 


{ 


ponteiro para buffer de mensagem */ 
flags da chamada de sistema */ 


/* 
/* 
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/ 


* Envia uma mensagem de'caller ptr' para 'dst”. Se 'dst' estiver bloqueado esperando 
* por essa mensagem, copia a mensagem nele e desbloqueia "dst'. Se "dst” não 


* estiver esperando nada ou se estiver esperando por outra origem, enfileira 'caller ptr”. 


*/ 
register struct proc *dst_ptr = proc_addr (dst); 
register struct proc **xpp; 
register struct proc *xp; 


/* Verifica impasse por causa de 'caller ptr' e '’dst’ enviando um para o outro. */ 
xp = dst ptr; 
while (xp->p rts flags & SENDING) 1 /* verifica enquanto envia */ 
xp = proc addr(xp->p sendto); /* obtém destino de xp */ 
if (xp == caller ptr) return(ELOCKED); /* impasse se for cíclico */ 
} 


/* Verifica se "dst” está bloqueado esperando por essa mensagem. O flag SENDING do 
* destino pode ser ativado quando sua chamada de SENDREC bloqueou durante o envio. 
*/ 

if C (dst ptr->p rts flags & (RECEIVING | SENDING)) == RECEIVING && 

(dst ptr->p getfrom == ANY || dst ptr->p getfrom == caller ptr->p nr) { 
/* O destino está mesmo esperando por essa mensagem. */ 
CopyMess(caller ptr->p nr, caller ptr, m ptr, dst ptr, 
dst ptr->p messbuf); 
if (Cdst ptr->p rts flags &= “RECEIVING) == 0) enqueue(dst ptr); 
} else if ( ! (flags & NON BLOCKING)) 1 


/* O destino não está esperando. Bloqueia e retira o processo que fez a chamada da fila. 


caller ptr->p messbuf = m ptr; 

if (caller ptr->p rts flags == 0) dequeue(caller ptr); 
caller ptr->p rts flags |= SENDING; 

caller ptr->p sendto = dst; 


/* Agora o processo está bloqueado. Coloca na fila do destino. */ 


xpp = &dst ptr->p caller q; /* find end of list */ 

while (*xpp != NIL PROC) xpp = &C*xpp)->p q link; 

*xpp = caller ptr; /* add caller to end */ 

caller ptr->p q link = NIL PROC; /* marca o novo fim da lista */ 
} else { 

return (ENOTREADY) ; 
} 
return(0K); 


PRIVATE int mini receive(caller ptr, src, m_ptr, flags) 


register struct proc *caller ptr; /* processo tentando obter mensagem */ 
int src; /* que origem de mensagem é desejada */ 
message *m ptr; /* ponteiro para buffer de mensagem */ 
unsigned flags; /* flags da chamada de sistema */ 

{ 


/* Um processo ou uma tarefa quer obter uma msg. Se uma mensagem já estiver enfileirada, a 


*/ 


* adquire e desbloqueia o remetente. Se nenhuma msg da origem desejada estiver disponível, 


* bloqueia o processo que fez a chamada, a não ser que os flags não permitam bloqueio. 


#/ 

register struct proc **xpp; 

register struct notification **ntf_q_pp; 
message m; 

int bit nr; 

Sys map t “map; 
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07657 
07658 
07659 
07660 
07661 
07662 
07663 
07664 
07665 
07666 
07667 
07668 
07669 
07670 
07671 
07672 
07673 
07674 
07675 
07676 
07677 
07678 
07679 
07680 
07681 
07682 
07683 
07684 
07685 
07686 
07687 
07688 
07689 
07690 
07691 
07692 
07693 
07694 
07695 
07696 
07697 
07698 
07699 
07700 
07701 
07702 
07703 
07704 
07705 
07706 
07707 
07708 
07709 
07710 
07711 
07712 
07713 
07714 


} 


bitchunk_t *chunk; 
int i, sre id, src proc nr; 


/* Verifica se uma mensagem da origem desejada já está disponível. O flag SENDING 
* do processo que fez a chamada pode ser ativado se SENDREC não conseguiu enviar. 
* Se ele for ativado, o processo deverá ser bloqueado. 
*/ 

if (!(caller ptr->p rts flags & SENDING)) 1 


} 


/* Verifica se existem notificações pendentes, exceto quanto a SENDREC. */ 


i 


} 


f C! (Cpriv(caller ptr)->s flags & SENDREC_BUSY)) { 


map = &priv(caller_ptr)->s_notify_pending; 


for (chunk=&map->chunk[0]; chunk<&map->chunk [NR SYS CHUNKS]; chunk++) 1 


/* Localiza uma notificação pendente a partir da origem solicitada. */ 


if (! *chunk) continue; 


/* nenhum bit no trecho */ 


for (i=0; ! (*chunk & (1<<i)); ++i) 1) /* pesquisa o bit */ 


src id = (chunk - &map->chunk[0]) * BITCHUNK BITS + i; 
if (src id >= NR SYS PROCS) break; /* fora do 
src proc nr = id to nr(src id); 


intervalo */ 


/* obtém proc de origem */ 


if (src!=ANY && src!=src proc nr) continue; /* origem não ok */ 


*chunk &= “(1 << i); 


/* não está mais pendente */ 


/* Encontra uma origem conveniente, envia a mensagem de notificação. */ 


BuildMess(&m, src proc nr, caller ptr); /* monta a 


mensagem */ 


CopyMess (src proc nr, proc addr(HARDWARE), &m, caller ptr, m ptr); 
return(OK) ; /* relata êxito */ 


/* Testa fila do proc.chamador (uso de ponteiros simplifica o código) */ 


x 


pp = &caller ptr->p caller q; 


while (*xpp != NIL PROC) { 


3 


if (src == ANY || src == proc nr(*xpp)) 1 


/* Encontra mensagem aceitável. A copia e atualiza o status. */ 
CopyMess(C*xpp)->p nr, *xpp, (:xpp)->p messbuf, caller ptr, m ptr); 
if CCC*xpp)->p rts flags &= “SENDING) == 0) enqueue(*xpp); 

*xpp = C*xpp)->p q link; /* remove da fila */ 


return(OK); /* relata êxito */ 
} 
xpp = &(*xpp)->p_q_link; 


/* passa para a próxima */ 


/* Nenhuma msg conveniente está disponível ou o processo que fez a chamada não pode enviar 


* 


em SENDREC. Bloqueia processo que tenta recebe-la, a não ser que 


if C ! (flags & NON BLOCKING)) { 


caller_ptr->p_getfrom = src; 

caller_ptr->p_messbuf = m_ptr; 

if (caller_ptr->p_rts_flags == 0) dequeue(caller_ptr); 
caller_ptr->p_rts_flags |= RECEIVING; 

return(0K); 


} else { 


} 


return (ENOTREADY) ; 


flags digam o contrário. 
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07716 

07717 

07718 3 

07719 PRIVATE int mini_notify(caller_ptr, dst) 

07720 register struct proc *caller_ptr; /* remetente da notificação */ 

07721 int dst; /* qual processo deve ser notificado */ 
07722 | 

07723 register struct proc *dst ptr = proc addr(dst); 

07724 int src id; /* id da origem para envio posterior */ 
07725 message m; /* a mensagem de notificação */ 

07726 

07727 /* Verifica se o destino está bloqueado esperando por essa mensagem. Um processo 
07728 * pode estar enviando e recebendo durante uma chamada de sistema SENDREC. 
07729 */ 

07730 if C(dst ptr->p rts flags & (RECEIVING|SENDING)) == RECEIVING && 

07731 ! Cpriv(dst ptr)->s flags & SENDREC BUSY) && 

07732 (dst ptr->p getfrom == ANY || dst ptr->p getfrom == caller ptr->p nr) { 
07733 

07734 /* O destino está mesmo esperando por uma mensagem. Monta uma mensagem de 
07735 * notificação e a envia. Copia da pseudo-origem HARDWARE, pois a 

07736 * mensagem está no espaço de endereçamento do núcleo. 

07737 R 

07738 BuildMess(&m, proc nr(caller ptr), dst_ptr); 

07739 CopyMess (proc nr(caller ptr), proc addr (HARDWARE), &m, 

07740 dst ptr, dst ptr->p messbuf); 

07741 dst ptr->p rts flags &= “RECEIVING; /* desbloqueia o destino */ 
07742 if (dst ptr->p rts flags == 0) enqueue(dst ptr); 

07743 return(OK); 

07744 } 

07745 

07746 /* O destino não está pronto para receber a notificação. Adiciona-o no 

07747 * mapa de bits com notificações pendentes. Observe o procedimento indireto: a id do 
07748 * sistema, em vez do número do processo, é usada no mapa de bits pendente. 
07749 */ 

07750 src id = priv(caller ptr)->s id; 


07751 set sys bit(priv(dst ptr)->s notify pending, src id); 
07752 return(OK) ; 


07753 + 

07755 /*================2=2222 

07756 ? lock notify i 

07757 = ========== ==== 

07758 PUBLIC int lock_notify(src, dst) 

07759 int src; /* o remetente da notificação */ 

07760 int dst; /* quem vai ser notificado */ 

07761 { 

07762 /* Gateway seguro para mini_notify() para tarefas e rotinas de tratamento de interrupção. 
07763 * O remetente é dado explicitamente para evitar confusão sobre a origem da chamada. O 
07764 * núcleo do MINIX não é reentrante, o que significa que as interrupções são desativadas 
07765 * após a primeira entrada do núcleo (interrupção de hardware, armadilha ou exceção). 
07766 * O travamento é feito desativando-se a interrupções temporariamente. 

07767 */ 

07768 int result; 

07769 

07770 /* Ocorreu uma exceção ou uma interrupção, assim já está travado. */ 

07771 if (k reenter >= 0) { 

07772 result = mini_notify(proc_addr(src), dst); 

07773 } 

07774 


07775 /* Chamada do nível de tarefa, é exigido travamento. */ 
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07776 
07777 
07778 
07779 
07780 
07781 
07782 


07784 
07785 
07786 
07787 
07788 
07789 
07790 
07791 
07792 
07793 
07794 
07795 
07796 
07797 
07798 
07799 
07800 
07801 
07802 
07803 
07804 
07805 
07806 
07807 
07808 
07809 
07810 
07811 
07812 
07813 
07814 
07815 
07816 
07817 
07818 


07820 
07821 
07822 
07823 
07824 
07825 
07826 
07827 
07828 
07829 
07830 
07831 
07832 
07833 
07834 
07835 


else 1 
lock(0, "notify"); 
result = mini notifyC(proc addr(src), dst); 


unlock(0); 
} 
return(result); 
} 
Jic a 
$ enqueue + 
a A 
PRIVATE void enqueue(rp) 
register struct proc *rp; /* agora este processo é executável */ 
{ 
/* Adiciona ’rp’ em uma das filas de processos executáveis. Esta função é 
* responsável por inserir um processo em uma das filas do escalonador. 
* O mecanismo é implementado aqui. A política de escalonamento real é 
* definida em schedO e pick procQ. 
*/ 
int q; /* fila de escalonamento a usar */ 
int front; /* adiciona no início ou no fim */ 
/* Determina onde vai inserir no processo. */ 
sched(rp, &g, &front); 
/* Agora adiciona o processo na fila. */ 
if (rdy head[q] == NIL PROC) { /* adiciona na fila vazia */ 
rdy head[q] = rdy taillg] = rp; /* cria uma nova fila */ 
rp->p nextready = NIL PROC; /* marca o novo fim */ 
} 
else if (front) { /* adiciona no início da fila */ 
rp->p_nextready = rdy_head[q]; /* início do encadeamento da fila */ 
rdy_head[q] = rp; /* configura novo início da fila */ 
} 
else { /* adiciona no fim da fila */ 
rdy_tail[q]->p_nextready = rp; /* fim do encadeamento da fila */ 
rdy_tail[q] = rp; /* configura novo fim da fila */ 
rp->p nextready = NIL PROC; /* marca novo fim */ 
} 
/* Agora seleciona o próximo processo a executar. */ 
pick proc); 
} 
Ji 
kd dequeue * 
A 
PRIVATE void dequeue(rp) 
register struct proc *rp; /* este processo não é mais executável */ 


{ 
/* Um processo deve ser removido das filas de escalonamento, por exemplo, porque 
* ele foi bloqueado. Se o processo correntemente ativo for removido, um novo processo 


* será escolhido para executar, chamando pick_proc(). 


*/ 
register int q = rp->p_priority; /* fila a usar */ 
register struct proc **xpp; /* iteração na fila */ 


register struct proc *prev xp; 


/* Efeito colateral do núcleo: verifica se a pilha da tarefa ainda está ok? */ 
if (iskernelpCrp)) { 
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07836 if CeprivCrp)->s stack guard != STACK GUARD) 

07837 panic("stack overrun by task”, proc nr(rp)); 

07838 } 

07839 

07840 /* Agora certifica-se de que o processo não está em sua fila de processos prontos. Remove 
07841 * o processo, se for encontrado. Um processo pode deixar de estar pronto, mesmo que 
07842 * não esteja em execução, sendo enviado um sinal que o elimina. 

07843 TÁ 


07844 prev xp = NIL PROC; 
07845 for (xpp = &rdy head[q]; *xpp != NIL PROC; xpp = &(*xpp)->p nextready) { 
07846 


07847 if Céxpp == rp) É /* encontra processo a remover */ 
07848 *xpp = (:xpp)->p nextready; /* substitui pelo novo encadeamento */ 
07849 if (rp == rdy_tail[q]) /* fim da fila removido */ 

07850 rdy_tail[q] = prev xp; /* configura novo fim */ 

07851 if (rp == proc ptr || rp == next ptr) /* processo ativo removido */ 

07852 pick proc; /* escolhe novo processo a executar */ 
07853 break; 

07854 

07855 prev xp = *xpp; /* salva o anterior no encadeamento */ 
07856 } 

07857 } 

07859 /* === 

07860 * sched * 

07861 $ nsa 

07862 PRIVATE void sched(rp, queue, front) 

07863 register struct proc *rp; /* processo a ser escalonado */ 

07864 int *queue; /* retorna: fila a usar */ 

07865 int *front; /* retorna: início ou fim */ 

07866 { 

07867 /* Esta função determina a política de escalonamento. Ela é chamada quando 

07868 * um processo precisa ser adicionado em uma das filas de escalonamento para decidir onde 
07869 * inseri-lo. Como um efeito colateral, a prioridade do processo pode ser atualizada. 
07870 */ 

07871 static struct proc *prev_ptr = NIL_PROC; /* anterior sem tempo */ 

07872 int time_left = (rp->p_ticks_left > 0); /* quantum totalmente consumido */ 
07873 int penalty = 0; /* mudança na prioridade */ 

07874 

07875 /* Verifica se o processo tem tempo restante. Caso contrário, fornece um novo quantum 
07876 * e, possivelmente, aumenta a prioridade. Os processos que usam vários quanta 

07877 * em sequência recebem menor prioridade para capturar laços infinitos em 

07878 * processos de alta prioridade (servidores e drivers de sistema). 

07879 */ 

07880 if C ! time left) { /* quantum consumido ? */ 

07881 rp->p ticks left = rp->p quantum size; /* recebe novo quantum */ 

07882 if (prev ptr == rp) penalty ++; /* captura loops infinitos */ 

07883 else penalty --; /* fornece retrocesso lento */ 

07884 prev ptr = rp; /* armazena ptr para o próximo */ 
07885 } 

07886 

07887 /* Determina a nova prioridade desse processo. Os limites são determinados 

07888 * pela fila de IDLE e pela prioridade máxima desse processo. As tarefas do núcleo 
07889 * e o processo ocioso nunca mudam de prioridade. 

07890 */ 

07891 if (penalty != 0 & ! iskernelp(rp)) { 

07892 rp->p_priority += penalty; /* atualização com penalidade */ 

07893 if Crp->p priority < rp->p max priority) /* verifica o limite superior */ 

07894 rp->p priority=rp->p max priority; 


07895 else if (Crp->p priority > IDLE Q-1) /* verifica o limite inferior */ 


Apêndice B e O Cóbigo-FONTE DO MINIX 677 


07896 
07897 
07898 
07899 
07900 
07901 
07902 
07903 
07904 
07905 


07907 
07908 
07909 
07910 
07911 
07912 
07913 
07914 
07915 
07916 
07917 
07918 
07919 
07920 
07921 
07922 
07923 
07924 
07925 
07926 
07927 
07928 
07929 
07930 
07931 


07933 
07934 
07935 
07936 
07937 
07938 
07939 
07940 
07941 
07942 
07943 
07944 
07945 
07946 


07948 
07949 
07950 
07951 
07952 
07953 
07954 
07955 


rp->p priority = IDLE Q-1; 
} 


/* Se houver tempo restante, o processo é adicionado no início de sua fila, 
* para que possa ser executado imediatamente. A fila a ser usada é simplesmente sempre a 
* prioridade corrente do processo. 


*/ 
*queue = rp->p priority; 
“front = time left; 


PRIVATE void pic 

{ 

/* Decide quem vai executar agora. Um novo processo é selecionado configurando-se "next ptr”. 
* Quando um processo que pode ser cobrado é selecionado, registra-o em "bill ptr”, para que 
* a tarefa de relógio possa saber de quem vai cobrar pelo tempo do sistema. 
2y 

register struct proc *rp; /* processo a ser executado */ 
int q; /* iteração nas filas */ 


k procQO 


/* Verifica a existência de processos prontos em cada uma das filas de escalonamento. 
* O número de filas é definido em proc.h e as prioridades são configuradas na tabela 
* de imagem. A fila mais baixa contém IDLE, que está sempre pronto. 

*/ 
for (q=0; q < NR SCHED QUEUES; q++) { 
if C (rp = rdy head[q]) != NIL PROC { 


next ptr = rp; /* executa o processo 'rp' em seguida */ 
if CprivCrp)->s flags & BILLABLE) 
bill ptr = rp; /* cobrança pelo tempo do sistema */ 
return; 
} 
} 
} 
/* === ¥ 
* lock send * 


PUBLIC int lock send(dst, m ptr) 


int dst; /* para quem a mensagem está sendo enviada? */ 
message *m ptr; /* ponteiro para buffer de mensagem */ 
{ 


/* Gateway seguro para mini_send() para tarefas. */ 
int result; 
Tock(2, "send"); 
result = mini send(proc ptr, dst, m ptr, NON BLOCKING); 


unlock(2); 
return(result); 

} 

/* === ¥ 
* lock enqueue * 
a e A, 

PUBLIC void Tock enqueue(rp) 

struct proc *rp; /* agora este processo é executável */ 

{ 


/* Gateway seguro para enqueue() para tarefas. */ 
Tock(3, "enqueue"); 
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07956 enqueue(rp); 
07957 unlock(3); 


07958 } 

07960 — /Z======D=D=D=D=D==>=D>=>D"==2=D2==2D=D=>D>D2>2==2>=>D==2==2=02=>=>>=>="==2==>=>=>==========— * 
07961 $ lock_dequeue # 
07962 fDCDS=S====DDD2DD=DDDDDD=D=D==2D=D=02=02=02==D=D2==2=02=======>====2====>====>========="* / 
07963 PUBLIC void lock dequeue(rp) 

07964 struct proc “rp; /* este processo não é mais executável */ 

07965 1 


07966 /* Gateway seguro para dequeue() para tarefas. */ 
07967 lock(4, "dequeue"); 

07968 dequeue(rp); 

07969 unlock(4); 

07970 + 


AAA 
kernel/exception.c 
DO one Do o o O O O HEHHE HHHH HHHH HHHH HHH HHHH HHHH HHHH O DD H+ O O DO OO OO O O 


08000 /* Este arquivo contém uma rotina de tratamento de exceção simples. As exceções nos 
08001 * processos de usuário são convertidas em sinais. As exceções em uma tarefa do núcleo causam 


08002 * uma situação de pânico. 
08003 A 
08004 


08005 #include "kernel.h"” 
08006 #include <signal.h> 
08007 #include "proc.h" 


08008 

08009 | /%=================>=====>=>>=>>>=>>=>>>=>>>>>=>>>>>=>>=>>>>>>>>>>">=>=>>=>>>>>>=>>=>===="* 

08010 $ exception ü 

08011 *============= Y / 


08012 PUBLIC void exception(vec_nr) 
08013 unsigned vec_nr; 


08014 { 

08015 /* Ocorreu uma exceção ou uma interrupção inesperada. */ 
08016 

08017 struct ex_s { 

08018 char *msg; 

08019 int signum; 

08020 int minprocessor; 

08021 Fs 

08022 static struct ex_s ex_data[] = { 

08023 { "Divide error", SIGFPE, 86 }, 

08024 { "Debug exception", SIGTRAP, 86 }, 

08025 { "Nonmaskable interrupt", SIGBUS, 86 }, 
08026 { "Breakpoint", SIGEMT, 86 }, 

08027 { "Overflow", SIGFPE, 86 }, 

08028 { "Bounds check", SIGFPE, 186 }, 

08029 { "Invalid opcode", SIGILL, 186 }, 

08030 { "Coprocessor not available", SIGFPE, 186 }, 
08031 { "Double fault", SIGBUS, 286 }, 

08032 { "Copressor segment overrun", SIGSEGV, 286 }, 
08033 { "Invalid TSS", SIGSEGV, 286 }, 

08034 { "Segment not present", SIGSEGV, 286 }, 
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{ "Stack exception", SIGSEGV, 286 }, /* STACK FAULT já usada */ 

{ "General protection", SIGSEGV, 286 }, 

{ "Page fault”, SIGSEGV, 386 3, /* não fecha */ 

{ NIL PTR, SIGILL, O 3, /* provavelmente interrupção de software */ 
{ "Coprocessor error", SIGFPE, 386 3, 


3; 
register struct ex s *ep; 
struct proc *saved proc; 


/* Salva proc ptr, pois não pode ser alterado por instruções de depuração. */ 
saved proc = proc ptr; 


ep = &ex data[vec nr]; 


if (vec nr = 2) { /* NMI espúrio em algumas máquinas */ 
kprintfC"got spurious NMI\n"); 
return; 

} 


/* Se ocorrer uma exceção durante a execução de um processo, a variável k_reenter 
* será zero. As exceções nas rotinas de tratamento de interrupção ou em interrupções 
* do sistema tornarão k_reenter maior do que zero. 
*/ 
if (k_reenter == 0 && ! iskernelp(saved proc)) { 
cause sig(proc nr(saved proc), ep->signum); 
return; 


} 


/* Exceção no código do sistema. Isso não deveria acontecer. */ 

if (ep->msg == NIL PTR || machine.processor < ep->minprocessor) 
kprintf("\nIntel-reserved exception %d\n", vec nr); 

else 
kprintf("\n%s\n", ep->msg); 

kprintf('k reenter = %d ", k reenter); 

kprintf("process %d (%s), ", proc nr(saved proc), saved proc->p name); 

kprintfC"pc = %u:0x%x", (unsigned) saved proc->p reg.cs, 

(unsigned) saved proc->p reg.pc); 


panic("exception in a kernel task”, NO NUM); 


HEHEHEHEH HEHH HHHH HHH HH HH H+ HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH H+H+HH+HH+H+HH+H+H+H+H+H+ 


kerne1/18259.c 


HEHEHEHEHE HHHH HHHH HHHH HH HH HHHH H+H HHHH HHHH H+H HH H+H HHHH HHHH HHHH H+H+H+H+H+H+H+H+H+ 


08100 
08101 
08102 
08103 
08104 
08105 
08106 
08107 
08108 
08109 


/* Este arquivo contém rotinas para inicializar a controladora de interrupção 8259: 
* put_irq_handler: registra uma rotina de tratamento de interrupção 
rm_irq_handler: retira o registro de uma rotina de tratamento de interrupção 

intr_handle: trata de uma interrupção de hardware 

* intr_init: inicializa a(s) controladora(s) de interrupção 


#include "kernel.h" 
#include "proc.h" 
#include <minix/com.h> 
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08110 

08111 define ICW1 AT 0x11 * disparado pela margem, cascata, precisa de ICW4 */ 
08112 &define ICW1 PC 0x13 * disparado pela margem, sem cascata, precisa de ICW4 */ 
08113 &define ICW1 PS 0x19 * disparado pelo nível, cascata, precisa de ICW4 */ 


08114 define ICW4 AT SLAVE 0x01 * sem SFNM, sem buffer, EOI normal, 8086 */ 
08115 define ICW4 AT MASTER 0x05 * sem SFNM, sem buffer, EOI normal, 8086 */ 
08116 define ICW4 PC SLAVE 0x09 * sem SFNM, com buffer, EOI normal, 8086 */ 
08117 define ICW4 PC MASTER 0x0D /* sem SFNM, com buffer, EOI normal, 8086 */ 


08118 


oras 


08119 &define set vec(nr, addr) (Cvoid)0) 

08120 

08121  /%========>============>===>==>===>>==>>>=>===>==>>==>>=>>==>==>>>=>==>>==>==>>===>==* 
08122 * i k 


08123 $ === = 
08124 PUBLIC void intr_init(mine) 
08125 int mine; 


08126 { 

08127 /* Inicializa as 8259, terminando todas as interrupções desativadas. Isso só 
08128 * é feito no modo protegido; no modo real, não mexemos nas 8259, mas 

08129 * usamos, em vez disso, as posições da BIOS. O flag "mine" é ativado se as 8259 
08130 * forem programadas para o MINIX ou reconfiguradas com o que a BIOS espera. 
08131 */ 

08132 int i; 

08133 

08134 intr disableO; 

08135 

08136 /* O AT e o PS/2, mais recente, têm duas controladoras de interrupção, uma mestra e 
08137 * uma escrava no IRQ 2. (Não temos que lidar com o PC, que 

08138 * tem apenas uma controladora, pois ele deve executar no modo real.) 

08139 */ 

08140 outb(INT CTL, machine.ps mca ? ICW1 PS : ICWI AT); 

08141 outb (INT CTLMASK, mine ? IRQO VECTOR : BIOS IRQO VEC); 

08142 /* ICW2 para a mestra */ 
08143 outb (INT CTLMASK, (1 << CASCADE IRQ)); /* ICW3 informa às escravas */ 
08144 outb(INT CTLMASK, ICW4 AT MASTER); 

08145 outb (INT CTLMASK, “(1 << CASCADE IRQ)); /* máscara IRQ 0-7 */ 
08146 outb(INT2 CTL, machine.ps mca ? ICW1 PS : ICWI AT); 

08147 outb(INT2 CTLMASK, mine ? IRQ8 VECTOR : BIOS IRQ8 VEC); 

08148 /* ICW2 para a escrava */ 
08149 outb(INT2 CTLMASK, CASCADE IRQ); /* ICW3 é a escrava nr */ 

08150 outb(INT2 CTLMASK, ICW4 AT SLAVE); 

08151 outb(INT2 CTLMASK, “0); /* máscara IRQ 8-15 */ 
08152 

08153 /* Copia os vetores da BIOS para a posição do Minix; portanto, ainda 

08154 * podemos fazer chamadas de BIOS sem reprogramar as i8259. 

08155 */ 

08156 phys copy(BIOS VECTOR(O) * 4L, VECTOR(O) * 4L, 8 * 4L); 

08157 } 

08159  /*===DDDD>D=>DDDDDDDDDDDDDDDDDDDDDDDD0D02D0DDDDDDDD0DDD=D>D>=D>=2>=>=>=>>=>>=>>=>=>* 
08160 z put_irq_handler * 
08161 PEDE / 


08162 PUBLIC void put irq handler(hook, irq, handler) 

08163 irq hook t *hook; 

08164 int irq; 

08165 irq_handler_t handler; 

08166 { 

08167 /* Registra uma rotina de tratamento de interrupção. */ 
08168 int id; 

08169 irq_hook_t **line; 
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08170 
08171 
08172 
08173 
08174 
08175 
08176 
08177 
08178 
08179 
08180 
08181 
08182 
08183 
08184 
08185 
08186 
08187 
08188 
08189 
08190 


08192 
08193 
08194 
08195 
08196 
08197 
08198 
08199 
08200 
08201 
08202 
08203 
08204 
08205 
08206 
08207 
08208 
08209 
08210 
08211 
08212 
08213 
08214 
08215 
08216 


08218 
08219 
08220 
08221 
08222 
08223 
08224 
08225 
08226 
08227 
08228 
08229 


if Cirq < 0 || irq >= NR IRQ VECTORS) 
panic("invalid call to put irq handler", irq); 


line = &irq handlers[irgl; 


id = 

while (“line != NULL) { 
if Chook == *Tine) return; /* inicialização extra */ 
line = LC Tino) -snext: 
id <<= 1; 

} 


if Cid == 0) panic("Too many handlers for irq", irq); 


hook->next = NULL; 
hook->handler = handler; 
hook->irq = irq; 
hook->id = id; 

“Tine = hook; 


irq_use |= 1 << irq; 


PUBLIC void rm_irq_handler (hook) 

irq_hook_t *hook; 

{ 

/* Retira o registro de uma rotina de tratamento de interrupção. */ 
int irq = hook->irq; 
int id = hook->id; 
irq_hook_t **line; 


if Cirq < 0 || irq >= NR_IRQ_VECTORS) 
panic("invalid call to rm_irq_handler", irq); 


line = &irq_handlers[irq]; 
while (*line != NULL) { 
if ((*line)->id == id) { 
(*line) = (*line)->next; 
if (! irq_handlers[irq]) irq use &= “(1 << irq); 
return; 
} 
line = &(*line)->next; 
} 


/* Quando a rotina de tratamento não é encontrada, normalmente retorna aqui. */ 


PUBLIC void intr_handle(hook) 
irq_hook_t *hook; 

{ 

/* Chama as rotinas de tratamento de interrupção para uma interrupção com a lista de ganchos 
* dada. A parte em assembly da rotina de tratamento já mascarou o IRQ, reativou a(s) 


*/ 


controladora(s) e ativou as interrupções. 


/* Chama a lista de rotinas de tratamento para um IRQ. */ 
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08230 
08231 
08232 
08233 
08234 
08235 
08236 
08237 
08238 
08239 
08240 
08241 
08242 


while (hook != NULL) { 


/* Para cada rotina de tratamento da lista, marca como ativa ativando seu bit de ID, 
* chama a função e desmarca, caso a função retorne true. 


# 


irq actids[hook->irq] |= hook->id; 
if (C*hook->handler)(hook)) irq actids[hook->irq] &= “hook->id; 


hook = hook->next; 


} 


/* Agora, o código em assembly desativa as interrupções, desmascara o IRQ se e somente 
* se todos os bits de ID ativos estiverem zerados e reinicia um processo. 


*/ 


HHHH HHH+H HHHH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH ++ 
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08300 
08301 
08302 
08303 
08304 
08305 
08306 
08307 
08308 
08309 
08310 
08311 
08312 
08313 
08314 
08315 
08316 
08317 
08318 
08319 
08320 
08321 
08322 
08323 
08324 
08325 
08326 
08327 
08328 
08329 
08330 
08331 
08332 
08333 
08334 
08335 
08336 
08337 
08338 
08339 


/* Este arquivo contém código para inicialização do modo protegido, para inicializar 
* descritores de segmento de código e de dados, e para inicializar descritores globais 


*/ 
#include "kernel.h" 
#include "proc.h" 


#include "protect.h" 


#define INT_GATE_TYPE 
#define TSS_TYPE 


struct desctableptr_s { 


char limit[sizeof(u16_t)]; 


char base[sizeof(u32_t)]; 
+; 


struct gatedesc s { 
ul6 t offset low; 
ul6 t selector; 
u8 t pad; 
u8 t p dpl type; 
ul6 t offset high; 
+; 


struct tsss { 


* para descritores locais na tabela de processos. 


CINT_286_GATE | DESC 386 BIT) 
CAVL 286 TSS 


| DESC 386 BIT) 


/* really u24 t + pad for 286 */ 


/* |000]XXXXX| ig & trpg, 
/* |PIDL|O|TYPE| */ 


|XXXXXXXX| tarefa g */ 


reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 


backlink; 
sp0; 

ss0; /* 
sp1; 

ss1; 

sp2; 

ss2; 

cr3; 

ip; 

flags; 

ax; 

EXE 

dx; 

bx; 


/* ponteiro de pilha para usar durante a interrupção */ 


non u " */ 


segmento 
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08340 
08341 
08342 
08343 
08344 
08345 
08346 
08347 
08348 
08349 
08350 
08351 
08352 
08353 
08354 
08355 
08356 
08357 


08358 
08359 
08360 
08361 
08362 
08363 
08364 
08365 
08366 
08367 
08368 
08369 
08370 
08371 
08372 
08373 
08374 
08375 
08376 
08377 
08378 
08379 
08380 
08381 
08382 
08383 
08384 
08385 
08386 
08387 
08388 
08389 
08390 
08391 
08392 
08393 
08394 
08395 
08396 
08397 
08398 
08399 


reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
reg t 
ul6 t 
ul6 t 
/* u8 t 
+; 


Sp; 

bp; 

si; 

di; 

es; 

cs; 

ss; 

ds; 

fs; 

gs; 
ldt; 
trap; 
iobase; 
iomap[0]; */ 


PUBLIC struct segdesc_s gdt[GDT_SIZE]; /* usado em klib.s e mpx.s */ 
struct gatedesc_s idt[IDT_SIZE]; /* inicialização zero; portanto, nenhum 


PRIVATE 


presente */ 


PUBLIC struct tss s tss; /* inicialização zero */ 


FORWARD 


FORWARD 


- PROTOTYPE( void int gate, (unsigned vec nr, vir bytes offset, 
unsigned dpl type) ); 

- PROTOTYPE( void sdesc, (struct segdesc s *segdp, phys bytes base, 
vir bytes size) ); 


PUBLIC void prot initO 


{ 


/* Configura tabelas para o modo protegido. 
* Todas as entradas da GDT são alocadas no momento da compilação. 


*/ 


struct gate_table_s *gtp; 
struct desctableptr_s *dtp; 
unsigned ldt_index; 
register struct proc *rp; 


static struct gate_table_s { 


- PROTOTYPE( void (*gate), (void) ); 
unsigned char vec_nr; 
unsigned char privilege; 


7 
gate_table[] = { 


divide_error, DIVIDE_VECTOR, INTR_PRIVILEGE }, 
single_step_exception, DEBUG_VECTOR, INTR_PRIVILEGE }, 
nmi, NMI_VECTOR, INTR_PRIVILEGE }, 

breakpoint_exception, BREAKPOINT_VECTOR, USER_PRIVILEGE }, 
overflow, OVERFLOW_VECTOR, USER_PRIVILEGE }, 
bounds_check, BOUNDS_VECTOR, INTR_PRIVILEGE }, 
inval_opcode, INVAL_OP_VECTOR, INTR_PRIVILEGE }, 
copr_not_disponível, COPROC_NOT_VECTOR, INTR_PRIVILEGE }, 
double_fault, DOUBLE_FAULT_VECTOR, INTR_PRIVILEGE }, 
copr_seg_overrun, COPROC_SEG_VECTOR, INTR_PRIVILEGE }, 
inval_tss, INVAL_TSS_VECTOR, INTR_PRIVILEGE }, 
segment_not_present, SEG_NOT_VECTOR, INTR_PRIVILEGE }, 
stack_exception, STACK_FAULT_VECTOR, INTR_PRIVILEGE }, 
general_protection, PROTECTION_VECTOR, INTR_PRIVILEGE }, 
page_fault, PAGE_FAULT_VECTOR, INTR_PRIVILEGE }, 
copr_error, COPROC_ERR_VECTOR, INTR_PRIVILEGE }, 


manmanan 


684 


SISTEMAS OPERACIONAIS 


08400 
08401 
08402 
08403 
08404 
08405 
08406 
08407 
08408 
08409 
08410 
08411 
08412 
08413 
08414 
08415 
08416 
08417 
08418 
08419 
08420 
08421 
08422 
08423 
08424 
08425 
08426 
08427 
08428 
08429 
08430 
08431 
08432 
08433 
08434 
08435 
08436 
08437 
08438 
08439 
08440 
08441 
08442 
08443 
08444 
08445 
08446 
08447 
08448 
08449 
08450 
08451 
08452 
08453 
08454 
08455 
08456 
08457 
08458 
08459 


hwint00, VECTOR(C 0), INTR PRIVILEGE 
hwint01, VECTOR(C 1), INTR PRIVILEGE 
hwint02, VECTOR( 2), INTR PRIVILEGE 
hwint03, VECTOR(C 3), INTR PRIVILEGE 
hwint04, VECTOR(C 4), INTR PRIVILEGE 
hwint05, VECTORC 5), INTR PRIVILEGE 
hwint06, VECTOR(C 6), INTR PRIVILEGE 
hwint07, VECTOR(C 7), INTR PRIVILEGE 
hwint08, VECTOR(C 8), INTR PRIVILEGE 
hwint09, VECTOR(C 9), INTR PRIVILEGE 
hwint10, VECTOR(10), INTR PRIVILEGE 
hwintll, VECTOR(11), INTR PRIVILEGE 
hwint12, VECTOR(12), INTR PRIVILEGE 
hwint13, VECTOR(13), INTR PRIVILEGE 
hwint1l4, VECTOR(14), INTR PRIVILEGE 
hwint15, VECTOR(15), INTR PRIVILEGE 4, 
s call, SYS386 VECTOR, USER PRIVILEGE 3, /* chamada de sistema do 386 */ 
TevelO call, LEVELO VECTOR, TASK PRIVILEGE 3, 


[a RE nao na RE nao Roo Naa Roo Dna nnmnnn 
a a ho a ai ao aÃ ado adia ada adia ada 2d 


3; 


/* Constrói ponteiros de gdt e idt na GDT, onde a BIOS espera que eles estejam. */ 
dtp= (struct desctableptr s *) &gdt [GDT INDEX]; 

* (ul6 t *) dtp->limit = (sizeof gdt) - 1; 

* (u32 t *) dtp->base = vir2phys(gdt); 


dtp= (struct desctableptr s *) &gdt [IDT INDEX]; 
* (ul6 t *) dtp->limit = (sizeof idt) - 1; 
* (u32 t *) dtp->base = vir2phys(idt); 


/* Constrói descritores de segmento para tarefas e rotinas de tratamento de interrupção. * 


init codeseg(&gdt [CS INDEX], 

kinfo.code base, kinfo.code size, INTR PRIVILEGE); 
init dataseg(&gdt [DS INDEX], 

kinfo.data base, kinfo.data size, INTR PRIVILEGE); 
init dataseg(&gdt [ES INDEX], OL, O, TASK PRIVILEGE); 


/* Constrói descritores de rascunho para funções em klib88. */ 
init dataseg(&gdt [DS 286 INDEX], OL, O, TASK PRIVILEGE) ; 
init dataseg(&gdt [ES 286 INDEX], OL, O, TASK PRIVILEGE); 


/* Constrói descritores locais na GDT para LDTs na tabela de processos. 
* Os LDTs são alocados na tabela de processos no momento da compilação e 
* inicializados quando o mapa de um processo é inicializado ou alterado. 
for (rp = BEG PROC ADDR, ldt index = FIRST LDT INDEX; 
rp < END PROC ADDR; ++rp, Tdt index++) 1 
init dataseg(&gdt[Tdt index], vir2physCrp->p Tdt), 
sizeof(rp->p ldt), INTR PRIVILEGE); 
gdt[ldt index].access = PRESENT | LDT; 
rp->p ldt sel = ldt index * DESC SIZE; 


/* Constrói a TSS principal. 
* Isso é usado apenas para registrar o ponteiro de pilha para ser usado após 
* uma interrupção. 
* O ponteiro é configurado de modo que uma interrupção salve automaticamente os 
* registradores do processo corrente ip:cs:f:sp:ss nas entradas corretas da 
* tabela de processos. 


tss.ss0 = DS SELECTOR; 
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08460 
08461 
08462 
08463 
08464 
08465 
08466 
08467 
08468 
08469 
08470 
08471 
08472 


08474 
08475 
08476 
08477 
08478 
08479 
08480 
08481 
08482 
08483 
08484 
08485 
08486 
08487 
08488 


08490 
08491 
08492 
08493 
08494 
08495 
08496 
08497 
08498 
08499 
08500 
08501 
08502 
08503 


08505 
08506 
08507 
08508 
08509 
08510 
08511 
08512 
08513 
08514 
08515 
08516 
08517 
08518 
08519 


init dataseg(&gdt[TSS INDEX], 


vir2phys(&tss), 


sizeof(tss), INTR PRIVILEGE); 


gdt[TSS INDEX] .access = PRESENT | (INTR PRIVILEGE << DPL SHIFT) | TSS TYPE; 


/* Constrói descritores para portas de interrupção na IDT. 


for (gtp = &gate table[0]; 


*/ 


gtp < &gate table[sizeof gate table / sizeof gate table[0]]; ++gtp) { 
(vir bytes) gtp->gate, 
PRESENT | INT GATE TYPE | Cgtp->privilege << DPL SHIFT)); 


int gate(gtp->vec nr, 


} 


/* Completa a construção da TSS principal. */ 
esvazia o mapa de permissões de E/S */ 


tss.iobase = sizeof tss; 


/* 


PUBLIC void init_codeseg(segdp, “base; size, privilege) 
register struct segdesc_s *segdp; 


phys_bytes base; 
vir_bytes size; 
int privilege; 


{ 


/* Constrói descritor para um segmento de código. */ 


sdesc(segdp, base, size); 


segdp->access = (privilege << DPL_SHIFT) 
| CPRESENT | SEGMENT | EXECUTABLE | READABLE); 
/* CONFORMING = 0, ACCESSED = 0 */ 


PUBLIC void init_dataseg(segdp, base, size, privilege) 
register struct segdesc_s *segdp; 


phys_bytes base; 
vir_bytes size; 
int privilege; 


{ 


/* Constrói descritor para um segmento de dados. */ 


sdesc(segdp, base, size); 


segdp->access = (privilege << DPL SHIFT) | (PRESENT | SEGMENT | WRITEABLE) ; 


/* EXECUTABLE = 


PRIVATE void sdesc(segdp, base, 


phys bytes base; 
vir bytes size; 


{ 


/* Preenche os campos de tamanho (base, 


segdp->base low = base; 


O, EXPAND DOWN = 


size) 
register struct segdesc s *segdp; 


segdp->base middle = base >> BASE MIDDLE SHIFT; 
segdp->base high = base >> BASE HIGH SHIFT; 


--size; 
if (size > BYTE GRAN MAX) 1 


/* 


converte para um limite; 


O, ACCESSED = 0 */ 


limite e granularidade) de um descritor. */ 


o tamanho O significa 4G * 
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08520 segdp->limit low = size >> PAGE GRAN SHIFT; 

08521 segdp->granularity = GRANULAR | (size >> 

08522 (PAGE GRAN SHIFT + GRANULARITY SHIFT)); 
08523 } else { 

08524 segdp->limit_low = size; 

08525 segdp->granularity = size >> GRANULARITY_SHIFT; 

08526 } 

08527 segdp->granularity |= DEFAULT; /* significa BIG para seg de dados */ 
08528 } 

08530 /* === 
08531 x seg2phys a 
08532 ERES CCO ES DESDE =ESS==S A SSSESSDESSSSSSESSS CEEE E ses Est / 


08533 PUBLIC phys bytes seg2phys(seg) 

08534 U16 t seg; 

08535 { 

08536 /* Retorna o endereço de base de um segmento, sendo seg um registrador de segmento do 
08537 * 8086 ou um seletor de segmento do 286/386. 


08538 E, 

08539 phys bytes base; 

08540 struct segdesc s *segdp; 

08541 

08542 if (! machine.protected) { 

08543 base = hclick to physb(seg); 

08544 } else { 

08545 segdp = &gdt[seg >> 3]; 

08546 base = ((u32 t) segdp->base_low << 0) 

08547 | C(u32_t) segdp->base middle << 16) 

08548 | C(u32_t) segdp->base_high << 24); 

08549 } 

08550 return base; 

08551 + 

08553 /*============================= * 
08554 ii phys2seg * 
08555 PSD ee / 


08556 PUBLIC void phys2seg(seg, off, phys) 

08557 ul6 t *seg; 

08558 vir bytes “off; 

08559 phys bytes phys; 

08560 { 

08561 /* Retorna um seletor de segmento e o deslocamento a ser usado para obter um end. físico, 
08562 * para uso por um driver que esteja fazendo E/S de memória no intervalo A0000 - DFFFF. 


FLAT DS SELECTOR; 
08565 *off = phys; 


o 
oo 
Eu 
fon) 
D 
un 
D 
Q 
Il 


08571 PRIVATE void int_gate(vec_nr, offset, dpl_type) 
08572 unsigned vec_nr; 

08573 vir_bytes offset; 

08574 unsigned dpl_type; 


08575 { 

08576 /* Constrói descritor para um interrupt gate. */ 
08577 register struct gatedesc_s *idp; 

08578 


08579 idp = &idt[vec_nr]; 
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08580 
08581 
08582 
08583 
08584 


08586 
08587 
08588 
08589 
08590 
08591 
08592 
08593 
08594 
08595 
08596 
08597 
08598 


08600 
08601 
08602 
08603 
08604 
08605 
08606 
08607 
08608 
08609 
08610 
08611 
08612 
08613 
08614 
08615 
08616 
08617 
08618 
08619 
08620 
08621 
08622 
08623 
08624 
08625 
08626 
08627 
08628 
08629 
08630 
08631 
08632 
08633 
08634 
08635 
08636 
08637 
08638 
08639 


idp->offset low = offset; 

idp->selector = CS SELECTOR; 

idp->p dpl type = dpl type; 

idp->offset high = offset >> OFFSET HIGH SHIFT; 


PUBLIC void enable iopCpp) 
struct proc *pp; 


{ 


/* Autoriza processo de usuário a usar instruções de E/S. Altera os bits I/O Permission 


* na psw. Eles especificam o Current Permission Level menos privilegiado 

* permitido para executar instruções de E/S. Os usuários e servidores têm CPL 3. 
* Você não pode ter menos privilégio do que isso. O núcleo tem CPL 0; as tarefas, 
*/ 

pp->p_reg.psw |= 0x3000; 


PUBLIC void alloc_segments(rp) 
register struct proc *rp; 


{ 


/* Isto é chamado na inicialização do sistema a partir de main() e por do_newmap(). 


* O código tem uma função separada devido a todas as dependências de hardware. 
* Note que IDLE faz parte do núcleo e recebe TASK PRIVILEGE aqui. 

#/ 

phys_bytes code_bytes; 

phys_bytes data_bytes; 

int privilege; 


if (machine.protected) { 
data_bytes = (phys_bytes) (rp->p_memmap[S].mem_vir + 
rp->p_memmap[S].mem_len) << CLICK SHIFT; 
if (rp->p memmap[T] .mem Ten == 0) 
code bytes = data bytes; /* I&D comum, proteção deficiente */ 
else 
code bytes = (phys bytes) rp->p memmap[T].mem Ten << CLICK SHIFT; 
privilege = (iskernelp(rp)) ? TASK PRIVILEGE : USER PRIVILEGE; 
init codeseg(&rp->p Tdt[CS LDT INDEX], 
Cphys bytes) rp->p memmap[T] .mem phys << CLICK SHIFT, 
code bytes, privilege); 
init dataseg(&rp->p Tdt[DS LDT INDEX], 
Cphys bytes) rp->p memmap[D] .mem phys << CLICK SHIFT, 
data bytes, privilege); 
rp->p reg.cs = (CS LDT INDEX * DESC SIZE) | TI | privilege; 
rp->p reg.gs = 
rp->p reg.fs = 
rp->p reg.ss = 
rp->p reg.es = 
rp->p reg.ds = (DS LDT INDEX*DESC SIZE) | TI | privilege; 
} else { 
rp->p_reg.cs = click_to_hclick(rp->p_memmap[T] .mem_phys); 
rp->p_reg.ss = 
rp->p_reg.es = 
rp->p_reg.ds = click_to_hclick(rp->p_memmap[D] .mem_phys); 


CPL 1. 
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08640 } 


HHHHHEHHHHHHH EH O RO DO AD DO HHHH HHHH HHH HHHH H+H HH HHHH HHHH H+H O O O O OO OO O O 
kernel/klib.s 
DO spa Do O O A O DO HHH H+H HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO OO O O DD O 


08700 # 

08701 ! Escolhe entre as versões 8086 e 386 do código de núcleo de baixo nível. 
08702 

08703 include <minix/config.h> 

08704 #if WORD SIZE == 

08705 #include "klib88.s" 

08706 #else 

08707 #include "klib386.s" 

08708 #endif 


DO spa oo o O O +H OD O DO OD DO HHHH HHHH HHHH HH HHHH H+H HH HHHH HHH H+ HHH DO OO O O O 
kernel/k1ib386.s 
HHHEHEHHHHHHH +H HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O DO OO OD O O 


08800 # 

08801 ! seções 

08802 

08803 .sect .text; .sect .rom; .sect .data; .sect .bss 
08804 


08805 #include <minix/config.h> 
08806 #include <minix/const.h> 
08807 #include "const.h” 

08808 #include "sconst.h" 

08809 include "protect.h" 


08810 

08811 ! Este arquivo contém várias rotinas utilitárias em código assembly necessárias para o 
08812 ! núcleo. São elas: 

08813 


08814 .define monitor 
08815 .define int86 

08816 .define cp mess 
08817 .define exit 

08818 .define _ exit 

08819 .define | exit 
08820 .define __ main 
08821 .define | phys insw 
08822 .define | phys insb 
08823 .define _phys_outsw 
08824 .define phys outsb 
08825 .define enable irq 
08826 .define disable irq 
08827 .define phys copy 
08828 .define phys memset 
08829 „define mem rdw 
08830 .define reset 

08831 .define Jidle task 
08832 .define _level0 
08833 .define read tsc 
08834 .define read cpu flags 


sai do Minix e retorna para o monitor 

deixa o monitor fazer uma chamada de interrupção do 8086 
copia mensagens da origem para o destino 

fictícia para rotinas de biblioteca 

fictícia para rotinas de biblioteca 

fictícia para rotinas de biblioteca 

fictícia para GCC 

transfere dados da porta (controladora de disco) para a memória 
do mesmo modo, byte por byte 

transfere dados da memória para a porta (controladora de disco) 
do mesmo modo, byte por byte 

ativa um irq na controladora 8259 

desativa um irq 

copia dados de qualquer parte para qualquer parte na memória 
escreve padrão em qualquer parte na memória 

copia uma palavra de [segmento: deslocamento] 

reconfigura o sistema 

tarefa executada quando não há nenhum trabalho 

chama uma função no nível O 

lê o contador de ciclos (Pentium e superiores) 

lê o flags da cpu 
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08835 
08836 
08837 
08838 
08839 
08840 
08841 
08842 
08843 
08844 
08845 
08846 
08847 
08848 
08849 
08850 
08851 
08852 
08853 
08854 
08855 
08856 
08857 
08858 
08859 
08860 
08861 
08862 
08863 
08864 
08865 
08866 
08867 
08868 
08869 
08870 
08871 
08872 
08873 
08874 
08875 
08876 
08877 
08878 
08879 
08880 
08881 
08882 
08883 
08884 
08885 
08886 
08887 
08888 
08889 
08890 
08891 
08892 
08893 
08894 


! As rotinas só garantem a preservação dos registradores que o compilador C 
! espera que o sejam (ebx, esi, edi, ebp, esp, registradores de segmento e 
! bit de direção nos flags). 


«sect .text 


[EE===E== ES = E DDS DESSE Ss ss 2cs * 


! PUBLIC void monitor); 
! Retorna para o monitor. 


“monitor: 


mov 


016 mov 


mov 
mov 
mov 
mov 
mov 
pop 
pop 
pop 


016 retf 


esp, (mon sp) 
dx, SS SELECTOR 
ds, dx 

es, dx 

fs, dx 

gs, dx 

ss, dx 

edi 

esi 

ebp 


restaura ponteiro de pilha do monitor 
segmento de dados do monitor 


retorna para o monitor 


! PUBLIC void int860); 


_int86: 


cmpb 
jnz 
movb 
movb 
movb 
ret 
push 
push 
push 
push 
pushf 
cli 


inb 
movb 
inb 
push 
mov 
and 
outb 
movb 
outb 


mov 
mov 

xchg 
push 
push 
push 


(mon return), O 
of 

ah, 0x01 
C_reg86+ 0), ah 
(reg86+13), ah 


ebp 
esi 
edi 
ebx 


INT2 CTLMASK 

ah, al 

INT CTLMASK 

eax 

eax, (Cirq use) 

eax, ” [1<<CLOCK IRQ] 
INT CTLMASK 

al, ah 

INT2 CTLMASK 


eax, SS SELECTOR 
ss, ax 

esp, (mon sp) 

( reg86+36) 

( reg86+32) 

( reg86+28) 


o monitor está presente? 


um erro int 13 parece apropriado 
reg86.w.f = 1 (ativa flag de transporte) 
reg86.b.ah = 0x01 = “invalid command" 


salva registradores C 


salva flags 
nenhuma interrupção 


salva máscaras de interrupção 
mapa de IRQs em uso 

mantém o relógio pulsando 

ativa todos os IRQs vv não usados. 


segmento de dados do monitor 


troca pilhas 
parâmetros usados na chamada de INT 
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08895 
08896 
08897 
08898 
08899 
08900 
08901 
08902 
08903 
08904 
08905 
08906 
08907 
08908 
08909 
08910 
08911 
08912 
08913 
08914 
08915 
08916 
08917 
08918 
08919 
08920 
08921 
08922 
08923 
08924 
08925 
08926 
08927 
08928 
08929 
08930 
08931 
08932 
08933 
08934 
08935 
08936 
08937 
08938 
08939 
08940 
08941 
08942 
08943 
08944 
08945 
08946 
08947 
08948 
08949 
08950 
08951 
08952 
08953 
08954 


push ( reg86+24) 
push ( reg86+20) 
push ( reg86+16) 
push ( reg86+12) 
push C(_reg86+ 8) 
push ( reg86+ 4) 
push (_reg86+ 0) 


mov ds, ax ! seletores de dados restantes 
mov es, ax 
mov fs, ax 
mov gs, ax 
push cs 
push return ! endereço de retorno e seletor do núcleo 
016 jmpf 20+2*%4+10*4+2*4 (esp) ! faz a chamada 
return: 
pop (_reg86+ 0) 
pop ( reg86+ 4) 
pop ( reg86+ 8) 
pop ( reg86+12) 
pop ( reg86+16) 
pop ( reg86+20) 
pop ( reg86+24) 
pop ( reg86+28) 
pop ( reg86+32) 
pop ( reg86+36) 
Igdt C gdt+GDT SELECTOR) ! recarrega a tabela de descritores globais 
jmpf CS SELECTOR: csinit ! restaura tudo 
csinit: mov eax, DS SELECTOR 
mov ds, ax 
mov es, ax 
mov fs, ax 
mov gs, ax 
mov ss, ax 
xchg esp, C mon sp) ! destroca as pilhas 
lidt Cgdt+IDT SELECTOR) ! recarrega a tabela de descritores de interrupção 


andb Cgdt+TSS SELECTOR+DESC ACCESS), “0x02 ! zer bit TSS ocupada 
mov eax, TSS SELECTOR 
ltr ax ! set TSS register 


pop eax 
outb INT_CTLMASK 
movb al, ah 

outb INT2_CTLMASK 


restaura as máscaras de interrupção 


add Clost ticks), ecx ! registra os tiques de relógio perdidos 
popf ! restaura os flags 

pop ebx ! restaura os registradores C 

pop edi 

pop esi 

pop ebp 

ret 


! PUBLIC void cp mess(int src, phys clicks src clicks, vir bytes src offset, 
! phys_clicks dst_clicks, vir_bytes dst_offset); 
! Esta rotina faz uma cópia rápida de uma mensagem de qualquer parte no espaço 
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08955 


08956 
08957 
08958 
08959 
08960 
08961 
08962 
08963 
08964 
08965 
08966 
08967 
08968 
08969 
08970 
08971 
08972 
08973 
08974 
08975 
08976 
08977 
08978 
08979 
08980 
08981 
08982 
08983 
08984 
08985 
08986 
08987 
08988 
08989 
08990 
08991 
08992 
08993 
08994 
08995 
08996 
08997 
08998 
08999 
09000 
09001 
09002 
09003 
09004 
09005 
09006 
09007 
09008 
09009 
09010 
09011 
09012 
09013 
09014 


de endereçamento para qualquer outra parte. Ela também copia o endereço de origem 
fornecido como 
parâmetro para a chamada na primeira palavra da mensagem de destino. 


Note que o tamanho da mensagem, "Msize", está em DWORDS (e não em bytes) e deve ser 
configurado corretamente. Alterar a definição da mensagem no arquivo de tipo e não 
alterá-la aqui levará a um desastre total. 


CM ARGS = 4+4+4+4+4 14 +4+4+4+4 
! es ds edi esi eip proc scl sof dcl dof 
.align 16 
_cp_mess: 
cld 
push esi 
push edi 
push ds 
push es 
mov eax, FLAT_DS_SELECTOR 
mov ds, ax 
mov es, ax 
mov esi, CM_ARGS+4 (esp) ! clicks da orig 
sh] esi, CLICK_SHIFT 
add esi, CM ARGS+4+4(esp) ! deslocamento da orig 
mov edi, CM ARGS+4+4+4(esp) ! clicks do dst 
shl edi, CLICK_SHIFT 
add edi, CM_ARGS+4+4+4+4 (esp) ! deslocamento do dst 
mov eax, CM_ARGS (esp) ! número de processo do remetente 
stos ! copia número do remetente na mensagem do dest 
add esi, 4 ! não copia a primeira palavra 
mov ecx, Msize - 1 ! lembre-se de que a primeira palavra não conta 
rep 
movs ! copia a mensagem 
pop es 
pop ds 
pop edi 
pop esi 
ret ! isso é tudo, pessoal! 
J A a a [[[//[/[/[[ == === + 
17 exit * 


PUBLIC void exit; 
Algumas rotinas de biblioteca usam exit; portanto, fornece uma versão fictícia. 
As chamadas reais para exit não podem ocorrer no núcleo. 


O GNU CC gosta de chamar main a partir de main) por razões não evidentes. 
exit: 
— exit: 
exit: 
sti 
jmp exit 
main: 
ret 
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09015 

09016 

09017 

09018 Ž !* 

09019 ! PUBLIC void phys_insw(Port_t port, phys bytes buf, size_t count); 

09020 ! Insere um array a partir de uma porta de E/S. Versão de endereço absoluto de insw(. 
09021 

09022  phys insw: 

09023 push ebp 

09024 mov ebp, esp 

09025 cld 

09026 push edi 

09027 push es 

09028 mov ecx, FLAT DS SELECTOR 

09029 mov es, cx 

09030 mov edx, 8(ebp) ! porta para leitura 

09031 mov edi, 12(ebp) ! endereço de destino 

09032 mov ecx, 16(ebp) ! contador de bytes 

09033 shr ecx, 1 ! contador de palavras 

09034 rep 016 ins ! insere muitas palavras 

09035 pop es 

09036 pop edi 

09037 pop ebp 

09038 ret 

09039 

09040 

09041 | |%===================>=D==>=D=>=>=>>=>=2>=>=>>>=>=2>==2=>=>=>=>==>>==>>==>===>>==>=============== * 
09042 !* phys insb $ 
09043 [42s 
09044 ! PUBLIC void phys_insb(Port_t port, phys bytes buf, size_t count); 

09045 ! Insere um array a partir de uma porta de E/S. Versão de endereço absoluto de insb). 
09046 

09047 _phys_insb: 

09048 push ebp 

09049 mov ebp, esp 

09050 cld 

09051 push edi 

09052 push es 

09053 mov ecx, FLAT_DS_SELECTOR 

09054 mov es, CX 

09055 mov edx, 8(ebp) ! porta para leitura 

09056 mov edi, 12(ebp) ! endereço de destino 

09057 mov ecx, 16(ebp) ! contador de bytes 

09058 ! shr ecx, 1 ! contador de palavras 

09059 rep insb ! insere muitos bytes 

09060 pop es 

09061 pop edi 

09062 pop ebp 

09063 ret 

09064 

09065 

09066 

09067 

09068 á ! 

09069 ! PUBLIC void phys outsw(Port t port, phys bytes buf, size_t count); 

09070 ! Saída de um array em uma porta de E/S. Versão de endereço absoluto de outsw(). 
09071 

09072 .«align 16 


09073  phys outsw: 
09074 push ebp 
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09075 
09076 
09077 
09078 
09079 
09080 
09081 
09082 
09083 
09084 
09085 
09086 
09087 
09088 
09089 
09090 
09091 
09092 
09093 
09094 
09095 
09096 
09097 
09098 
09099 
09100 
09101 
09102 
09103 
09104 
09105 
09106 
09107 
09108 
09109 
09110 
09111 
09112 
09113 
09114 
09115 
09116 
09117 
09118 
09119 
09120 
09121 
09122 
09123 
09124 
09125 
09126 
09127 
09128 
09129 
09130 
09131 
09132 
09133 
09134 


mov 
cld 
push 
push 
mov 
mov 
mov 
mov 
mov 
shr 
rep 016 outs 
pop 
pop 


ebp, esp 


esi 

ds 

ecx, FLAT DS SELECTOR 
ds, cx 

edx, 8(ebp) 

esi, 12(ebp) 

ecx, 16(ebp) 

ecx, 1 


porta para escrita 
endereço de origem 
contador de bytes 
contador de palavras 
saída de muitas palavras 


phys outsb 


! PUBLIC void phys outsb(Port t port, phys bytes buf, size_t count); 
! Saída de um array em uma porta de E/S. Versão de endereço absoluto de outsb(). 


.«align 
“phys outsb: 
push 
mov 
cld 
push 
push 
mov 
mov 


16 


ebp 
ebp, esp 


esi 

ds 

ecx, FLAT DS SELECTOR 
ds, cx 

edx, 8(ebp) 

esi, 12(ebp) 

ecx, 16(ebp) 


ds 
esi 
ebp 


porta para escrita 
endereço de origem 
contador de bytes 
saída de muitos bytes 


! PUBLIC void enable irq(irq hook t *hook) 
! Ativa uma linha de pedido de interrupção zerando um bit da 8259. 


if CCirq actids[hook->irq] & “hook->id) == 0) 


| 
| 
! Código equivalente em C para hook->irg < 8: 
| 
| 


outb(INT CTLMASK, inbCINT CTLMASK) & “(1 << irq)); 


.«align 
“enable irq: 
push 
mov 
pushf 
cli 
mov 
mov 
mov 


16 


ebp 
ebp, esp 


eax, 8(ebp) 
ecx, 8(eax) 
eax, 12(eax) 


! hook 
! irq 
© d bit 
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09135 not eax 

09136 and “irq actids(ecx*4), eax ! zera esse bit de id 

09137 jnz en done ! ainda mascarado por outras rotinas de tratamento? 
09138 movb ah, “1 

09139 rolb ah, cl ! ah = “(1 << (irq % 8)) 

09140 mov edx, INT_CTLMASK ! ativa irq < 8 na 8259 mestra 
09141 cmpb cl, 8 

09142 jb of 

09143 mov edx, INT2_CTLMASK ! ativa irq >= 8 na 8259 escrava 
09144 0: inb dx 

09145 andb al, ah 

09146 outb dx ! zera bit na 8259 

09147 en_done:popf 

09148 leave 

09149 ret 

09150 

09151 

09152 ran 5525 D= DDS DDSESE SSD =SS=DDE=S=EsSS=SE ss =S===+ 
09153 disable irq * 
09154 !* = SenneSEAENEE E */ 
09155 ! PUBLIC int disable irq(irq hook t *hook) 

09156 ! Desativa uma linha de pedido de interrupção configurando um bit da 8259. 
09157 ! Código equivalente em C para irq < 8: 

09158 ! irq actids[hook->irq] |= hook->id; 

09159 ! outb(INT CTLMASK, inbCINT CTLMASK) | (1 << irq)); 

09160 ! Retorna true se a interrupção ainda não foi desativada. 

09161 

09162 .«align 16 

09163  disable irq: 

09164 push ebp 

09165 mov ebp, esp 

09166 pushf 

09167 cli 

09168 mov eax, 8(ebp) ! hook 

09169 mov ecx, 8(eax) Larg 

09170 mov eax, 12(eax) l -d bit 

09171 or _irq_actids(ecx*4), eax ! configura este bit de id 

09172 movb ah, 1 

09173 rolb ah, cl ! ah = (1 << (irq % 8)) 

09174 mov edx, INT_CTLMASK ! desativa irq < 8 na 8259 mestra 
09175 cmpb Cl, 8 

09176 jb of 

09177 mov edx, INT2 CTLMASK ! desativa irq >= 8 na 8259 escrava 
09178 O: inb dx 

09179 testb al, ah 

09180 jnz dis already ! já desativado? 

09181 orb al, ah 

09182 outb dx ! ativa bit na 8259 

09183 mov eax, 1 ! desativado por esta função 
09184 popf 

09185 leave 

09186 ret 

09187 dis_already: 

09188 xor eax, eax ! já desativado 

09189 popf 

09190 leave 

09191 ret 

09192 
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09194 
09195 
09196 
09197 
09198 
09199 
09200 
09201 
09202 
09203 
09204 
09205 
09206 
09207 
09208 
09209 
09210 
09211 
09212 
09213 
09214 
09215 
09216 
09217 
09218 
09219 
09220 
09221 
09222 
09223 
09224 
09225 
09226 
09227 
09228 
09229 
09230 
09231 
09232 
09233 
09234 
09235 
09236 
09237 
09238 
09239 
09240 
09241 
09242 
09243 
09244 
09245 
09246 
09247 
09248 
09249 
09250 
09251 
09252 
09253 


! PUBLIC void phys copy(phys bytes source, phys bytes destination, 
! phys_bytes bytecount); 
! Copia um bloco de memória física. 


PC_ARGS = 4+4+4+4 14 +4+4 
! es edi esi eip src dst len 


.align 16 
-phys copy: 
cld 
push esi 
push edi 
push es 
mov eax, FLAT_DS_SELECTOR 
mov es, ax 


mov esi, PC_ARGS (esp) 
mov edi, PC_ARGS+4(esp) 


mov eax, PC ARGS+4+4(esp) 
cmp eax, 10 ! evita sobrecarga de alinhamento para contagens pequenas 
jb pc small 
mov ecx, esi ! alinha origem, espera que o destino também esteja alinhado 
neg ecx 
and ecx, 3 ! contador para alinhamento 
sub eax, ecx 
rep 

eseg movsb 
mov ecx, eax 
shr ecx, 2 ! contador de dwords 
rep 

eseg movs 
and eax, 3 

pc smal7: 

xchg ecx, eax ! resto 
rep 


eseg movsh 


pop es 
pop edi 
pop esi 
ret 


! PUBLIC void phys memset(phys bytes source, unsigned Tong pattern, 
! phys_bytes bytecount); 
! Preenche um bloco de memória física com padrão. 


.align 16 
_phys_memset: 

push ebp 

mov ebp, esp 

push esi 


push ebx 
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09254 push ds 

09255 mov esi, 8(ebp) 

09256 mov eax, 16(ebp) 

09257 mov ebx, FLAT DS SELECTOR 

09258 mov ds, bx 

09259 mov ebx, 12(ebp) 

09260 shr eax, 2 

09261 fill start: 

09262 mov (esi), ebx 

09263 add esi, 4 

09264 dec eax 

09265 jnz fill_start 

09266 ! Ainda restam bytes? 

09267 mov eax, 16(ebp) 

09268 and eax, 3 

09269 remain_fill: 

09270 cmp eax, 0 

09271 jz fill done 

09272 movb bl, 12(ebp) 

09273 movb (esi), bl 

09274 add esi, 1 

09275 inc ebp 

09276 dec eax 

09277 jmp remain fill 

09278 fill done: 

09279 pop ds 

09280 pop ebx 

09281 pop esi 

09282 pop ebp 

09283 ret 

09284 

09285 |% === Ý 
09286 !* mem_rdw * 
09287 |lg===DDDDDD>DDDDDDDDDDDDDDD2DDDDDDDD0D0D02DDDDDDDD02D0DDDDDDD>=DD=D=>=>=>>=>=>=>==>* 
09288 ! PUBLIC ul6 t mem rdw(U16 t segment, ul6 t *offset); 

09289 ! Carrega e retorna palavra no segmento: deslocamento do ponteiro distante. 
09290 

09291 .«align 16 

09292 mem rdw: 

09293 mov cx, ds 

09294 mov ds, 4(esp) ! segmento 

09295 mov eax, 4+4(esp) ! deslocamento 

09296 movzx eax, (eax) ! palavra a retornar 

09297 mov ds, cx 

09298 ret 

09299 

09300 

09301 |*= 
09302 I* reset * 
09303 | |f===DDDDDDDDDDDDDDDDDDDDD2DDDDDDDDDD0D02DDDDDDDD02D0DDDDDDDD=2>=2D=>=>=>>=>=>=>==>* 
09304 ! PUBLIC void resetQO; 

09305 ! Reconfigura o sistema carregando a IDT com deslocamento O e interrompendo. 
09306 

09307 reset: 

09308 lidt (idt zero) 

09309 int 3 ! qualquer um serve, o 386 não gostará disso 
09310 .sect .data 

09311 idt_zero: .data4 0, 0 


09312 «sect .text 
09313 
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09314 
09315 
09316 
09317 
09318 
09319 
09320 
09321 
09322 
09323 
09324 
09325 
09326 
09327 
09328 
09329 
09330 
09331 
09332 
09333 
09334 
09335 
09336 
09337 
09338 
09339 
09340 
09341 
09342 
09343 
09344 
09345 
09346 
09347 
09348 
09349 
09350 
09351 
09352 
09353 
09354 
09355 
09356 
09357 
09358 
09359 
09360 
09361 
09362 
09363 
09364 
09365 
09366 
09367 
09368 
09369 
09370 
09371 
09372 
09373 


“die task: 


! Esta tarefa é chamada quando o sistema não tem mais nada a fazer. A instrução HLT 


! coloca o processador em um estado onde ele consome o mínimo de energia. 


push halt 
call _level0 ! TevelOChalt) 
pop eax 
jmp _idle_task 
halt: 
sti 
hlt 
cli 
ret 


PUBLIC void level0(void (*func)(void)) 


_level0: 

mov eax, 4(esp) 

mov (Clevelo func), eax 

int LEVELO VECTOR 

ret 
[aen e 
pa read_tsc 


! PUBLIC void read_tsc(unsigned long *high, unsigned long *Tow); 


! Lê o contador de ciclos da CPU. Pentium e superiores. 


.align 16 

“read tsc: 

.datal 0x0f ! esta é a instrução RDTSC 

.datal 0x31 ! ela coloca TSC em EDX:EAX 
push ebp 


mov ebp, 8(esp) 
mov (ebp), edx 
mov ebp, 12(esp) 
mov (ebp), eax 
pop ebp 


! PUBLIC unsigned Tong read cpu flags(void); 
! Lê os flags de status da CPU a partir de C. 
.«align 16 
“read cpu flags: 

pushf 

mov eax, (esp) 

popf 

ret 


Chama uma função no nível de permissão O. Isso permite que as tarefas do núcleo façam 
coisas que só são possíveis no nível mais privilegiado da CPU. 
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HEHEHEHEH HEHH HHHH HHHH H+H H+ HH HH HH H+H HH HHHH HHHH H+H HHHH HHHH H+HHH+HH+H+H+H+H+H+H+H+H+ 


09400 
09401 
09402 
09403 
09404 
09405 
09406 
09407 
09408 
09409 
09410 
09411 
09412 
09413 
09414 
09415 
09416 
09417 
09418 
09419 
09420 
09421 
09422 
09423 
09424 
09425 
09426 
09427 
09428 
09429 
09430 
09431 
09432 
09433 
09434 
09435 
09436 
09437 
09438 
09439 
09440 
09441 
09442 
09443 
09444 
09445 


09447 
09448 
09449 
09450 
09451 
09452 
09453 
09454 


/* 


Este arquivo contém uma coleção de diversas funções: 
panic: aborta o MINIX devido a um erro fatal 
kprintf: saída de diagnóstico do núcleo 

* Alterações: 

10 de dezembro de 2004 impressão do núcleo no buffer circular (Jorrit N. Herder) 
Este arquivo contém as rotinas que cuidam das mensagens do núcleo, isto é, 
saída de diagnóstico dentro do núcleo. As mensagens do núcleo não são exibidas 
diretamente no console, pois isso deve ser feito pelo driver de saída. 

Em vez disso, o núcleo acumula caracteres em um buffer e notifica o 
driver de saída quando uma nova mensagem está pronta. 
JA 

nclude <minix/com.h> 


#i 
#i 
#i 
#i 
#i 
#i 
#i 
#i 


#d 


nclude "kernel.h" 
nclude <stdarg.h> 
nclude <unistd.h> 
nclude <stddef.h> 
nclude <stdlib.h> 
nclude <signal.h> 
nclude "proc.h" 


efine END_OF_KMESS -1 


FORWARD _PROTOTYPE(void kputc, (int c)); 


Vs 


PU 
o 
in 
{ 

/* 


PU 
{ 


BLIC void panic(mess,nr) 
ONST char *mess; 
tnr; 


O sistema travou devido a um erro fatal no núcleo. Termina a execução. */ 
static int panicking = 0; 
if (panicking ++) return; /* evita pânicos recursivos */ 


if (mess != NULL) { 
kprintf("inkernel panic: %s", mess); 
if (nr != NO NUM) kprintf(" %d", nr); 
kprintfC"Nn",NO NUM); 

} 


/* Aborta o MINIX. */ 
prepare shutdown(RBT PANIC); 


int c; /* próximo caractere em fmt */ 
int d; 
unsigned long u; /* contém argumento de número */ 
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int base; 

int negative = 0; 

static char x2c[] = "0123456789ABCDEF"; 
char ascii[8 * sizeof(long) / 3 + 2]; 
char *s = NULL; 

va list argp; 


va start(argp, fmt); 
while((c=*fmt++) != 0) 1 


if (c=="'%) 1 
switch(c = *fmt++) { 


/* As chaves conhecidas são %d, %u, 
* com tipos de número como %b e %o 


* As chaves de tipo de número não configuram uma string como 


* conversão geral após a instrução 
*/ 
case 'd': 

d = va arg(argp, signed int); 
if (d < 0) { negative = 1; u = 


/* base do arg de número */ 

/* imprime sinal de subtração */ 
/* tabela de conversão de nr */ 
/* string para número ascii */ 
/* string a ser impressa */ 

/* argumentos opcionais */ 


/* argumentos de variável de inic */ 


/* espera formato "key" */ 
/* determina o que fazer */ 


%x, %s e %%. Isso é facilmente estendido 
, fornecendo uma base diferente. 


tet 


S , mas usam a 


switch. 
/* saída em decimal */ 


-d; } else 


/* saída em long sem sinal */ 


/* saída em hexadecimal */ 


base = 10; 
break; 
case ’u’: 
u = va_arg(argp, unsigned long); 
base = 10; 
break; 
case 'x': 
u = va_arg(argp, unsigned long); 
base = 0x10; 
break; 
case ’s’: 


s = va arg(argp, char *); 
if (s == NULL) s = "(null)"; 


break; 
case '%': 
s = "%"; 
break; 
/* Chave não reconhecida. */ 
default: 
S = UM?" 
s[1] = c; 
} 


/* Assume um número, se nenhuma str 
if (s == NULL) { 
s = ascii + sizeof(ascii)-1; 
*s = 0; 
do { *--s = x2c[(u % base)]; + 
while (Cu /= base) > 0); 
} 


/* saída em string */ 


/* saída em porcentagem */ 


/* echo back %key */ 


/* configura chave desconhecida */ 


ing for configurada. Converte para ascii. */ 


/* vai para trás */ 


/* É aqui que a saída real do formato "key" é feita. */ 


if (negative) kputc('-'); 
while(*s != 0) { kputc(*s++); + 
s = NULL; 


else 1 


/* imprime o sinal, se for negativo */ 
/* imprime string/número */ 
/* reconfigura para próxima passagem */ 
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09515 kputc(c); /* imprime e continua */ 

09516 

09517 } 

09518 kputc (END_OF_KMESS) ; /* termina a saída */ 

09519 va_end(argp); /* fim de argumentos de variável */ 


09525 PRIVATE void kputc(c) 

09526 int c; /* caractere a anexar */ 

09527 1 

09528 /* Acumula um único caractere para uma mensagem do núcleo. Envia uma notificação 
09529 * para o driver de saída se for encontrado END OF KMESS. 


09530 */ 

09531 if (c != END OF KMESS) { 

09532 kmess.km_buf[kmess.km_next] = c; /* coloca car normal no buffer */ 
09533 if (kmess.km_size < KMESS_BUF_SIZE) 

09534 kmess.km size += 1; 

09535 kmess.km_next = (kmess.km_next + 1) % KMESS_BUF_SIZE; 

09536 } else { 

09537 send sig(OUTPUT PROC NR, SIGKMESS); 

09538 } 

09539 } 


DO one oo O o a O HH HH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ +H O O SD DO O OD O O 
kernel/system.h 
DO ssa oo O SO O DS HHH H+H HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO OO OO O O 


09600 /* Prototypes de função para a biblioteca de sistema. 


09601 * A implementação está contida em src/kernel/system/. 

09602 * 

09603 * A biblioteca de sistema permite acesso a serviços de sistema fazendo uma chamada de 
09604 * núcleo. As chamadas de núcleo são transformadas em mensagens de requisição para a tarefa 
09605 * SYS que é responsável por manipular a chamada. Por convenção, sys call() é transformada 
09606 * em uma mensagem com tipo SYS CALL que é manipulada em uma função do cali(). 

09607 */ 

09608 


09609 #ifndef SYSTEM_H 

09610 #define SYSTEM_H 

09611 

09612 /* Inclusões comuns para a biblioteca de sistema. */ 
09613 #include "kernel.h" 

09614 #include "proto.h" 

09615 #include "proc.h" 

09616 

09617 /* Rotina de tratamento padrão para chamadas de núcleo não usadas. */ 
09618 | PROTOTYPE( int do unused, (message *m ptr) ); 

09619 | PROTOTYPE( int do exec, (message *m ptr) ); 

09620 | PROTOTYPE( int do fork, (message *m ptr) ); 

09621 | PROTOTYPE( int do newmap, (message *m ptr) ); 

09622 | PROTOTYPE( int do exit, (message *m ptr) ); 

09623 | PROTOTYPE( int do trace, (message *m ptr) ); 

09624 | PROTOTYPE( int do nice, (message *m ptr) ); 
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09625 | PROTOTYPE( int do copy, (message *m ptr) ); 


09626 #define do vircopy do copy 
09627 #define do physcopy do copy 
09628 | PROTOTYPE( int do vcopy, (message *m ptr) ); 
09629 #define do virvcopy do vcopy 


09630 #define do physvcopy do vcopy 

09631 | PROTOTYPE( int do umap, (message *m ptr) ); 
09632 | PROTOTYPE( int do memset, (message *m ptr) ); 
09633 |. PROTOTYPE( int do abort, (message *m ptr) ); 
09634 | PROTOTYPE( int do getinfo, (message *m ptr) ); 
09635 | PROTOTYPE( int do privctl, (message *m ptr) ); 
09636 | PROTOTYPE( int do segctl, (message *m ptr) ); 
09637 | PROTOTYPE( int do irqctl, (message *m ptr) ); 
09638 | PROTOTYPE( int do devio, (message *m ptr) ); 
09639 | PROTOTYPE( int do vdevio, (message *m ptr) ); 
09640 | PROTOTYPE( int do int86, (message *m ptr) ); 
09641 | PROTOTYPE( int do sdevio, (message *m ptr) ); 
09642 | PROTOTYPE( int do kill, (message *m ptr) ); 
09643 | PROTOTYPE( int do getksig, (message *m ptr) ); 
09644 | PROTOTYPE( int do endksig, (message *m ptr) ); 
09645 | PROTOTYPE( int do sigsend, (message *m ptr) ); 
09646 | PROTOTYPE( int do sigreturn, (message *m ptr) ); 
09647 | PROTOTYPE( int do times, (message *m ptr) ); 
09648 | PROTOTYPE( int do setalarm, (message *m ptr) ); 
09649 

09650 gendif /* SYSTEM H */ 

09651 

09652 

09653 


HHHEHEHHHHHHH HHHH HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH H+H O O O DO OO OD O O 
kernel/system.c 
DO ssa oo DO O O SD H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O DO OO O O O 


09700 /* Esta tarefa fornece uma interface entre os processos do sistema em espaço de núcleo e 
09701 de usuário. Os serviços de sistema podem ser acessados fazendo-se uma chamada de 
09702 núcleo. As chamadas de núcleo são transformads em mensagens de requisição, as quais são 
09703 * manipuladas por essa tarefa. Por convenção, uma chamada sys call() é transformada em 


E 


* 


09704 * uma mensagem de requisição SYS CALL que é manipulada em uma função chamada do cal1O. 
09705 * 

09706 * Um vetor de chamada privado é usado para fazer o mapeamento de todas as chamadas de 
09707 * núcleo nas funções que as manipulam. As funções de tratamento reais estão contidas em 
09708 * arquivos separados para manter este arquivo limpo. O vetor de chamada é usado no laço 
09709 * principal da tarefa de sistema para tratar todas requisições recebidas. 

09710 ti 

09711 * Além do ponto de entrada principal de sys task), que inicia o loop principal, 

09712 * existem vários outros pontos de entrada secundários: 

09713 * get priv: atribui estrutura de privilégio para processo usuário ou sistema 
09714 * send sig: envia um sinal diretamente para um processo de sistema 

09715 * cause sig: executa ação para fazer um sinal ocorrer via GP 

09716 * —umap local: faz o mapeamento de endereço virtual em LOCAL SEG para físico 
09717 * —umap remote: faz o mapeamento de endereço virtual em REMOTE SEG para físico 
09718 *  umap bios: faz o mapeamento de endereço virtual em BIOS SEG para físico 
09719 * virtual copy: copia bytes de um endereço virtual para outro 

09720 * get randomness: acumula randomness em um buffer 

09721 * 

09722 * Alterações: (Jorrit N. Herder) 

09723 * 04 de agosto de 2005 verifica se chamada de núcleo é permitida 


09724 * 20 de julho de 2005 envia sinal para serviços com mensagem 
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09725 * 15 de janeiro de 2005 nova função de cópia virtual generalizada 

09726 * 10 de outubro de 2004 despacha chamadas de sistema a partir do vetor de chamada 
09727 * 30 de setembro de 2004 documentação do código-fonte atualizada 

09728 */ 

09729 


09730 include "kernel.h"” 

09731 #include "system.h"” 

09732 #include <stdlib.h> 

09733 #include <signal.h> 

09734 #include <unistd.h> 

09735 #include <sys/sigcontext.h> 
09736 #include <ibm/memory.h> 
09737 #include "protect.h” 


09738 

09739 /* Declaração do vetor de chamada que define o mapeamento de chamadas de núcleo 

09740 * para funções de tratamento. O vetor é inicializado em sys initQO) com mapO, 

09741 * que certifica-se de que os números de chamada de núcleo estejam certos. Nenhum espaço 
09742 * é alocado, pois a função fictícia é declarada como extern. Se for feita uma chamada 
09743 * inválida, o tamanho do array será negativo e isso não compilaria. 

09744 */ 

09745 PUBLIC int (*call vec[NR SYS CALLS]) (message *m ptr); 

09746 

09747 #define map(call nr, handler) \ 

09748 {extern int dummy [NR SYS CALLS>(Cunsigned) (call nr-KERNEL CALL) ? 1:-1];} N 

09749 call vec[(call nr-KERNEL CALL)] = (Chandler) 

09750 

09751 FORWARD PROTOTYPE( void initialize, (void)); 

09752 

09753 /f===DDDDDD=DDDDDDDDDDDDDDDDDDDDDDDDD0D0DDDDDDDD0D0DDDDDDDD=D>=D=>=>==>=>=>=>==>* 

09754 * sys task * 

09755 PCDS ee / 

09756 PUBLIC void sys task() 

09757 { 


09758 /* Ponto de entrada principal de sys task. Obtém a mensagem e despacha em type. */ 
09759 static message m; 


09760 register int result; 

09761 register struct proc *caller ptr; 

09762 unsigned int call nr; 

09763 int s; 

09764 

09765 /* Inicializa a tarefa de sistema. */ 

09766 initializeO; 

09767 

09768 while (TRUE) 1 

09769 /* Recebe trabalho. Bloqueia e espera até a chegada de uma mensagem de requisição. */ 

09770 receive(ANY, &m); 

09771 call nr = (unsigned) m.m type - KERNEL CALL; 

09772 caller ptr = proc addr(m.m source); 

09773 

09774 /* Verifica se o processo que fez a chamada fez uma requisição válida e tenta 
tratar dele. */ 

09775 if (! Cpriv(caller ptr)->s call mask & (1<<call_nr))) { 

09776 kprintfC'SYSTEM: request %d from %d denied.An", call nr,m.m source); 

09777 result = ECALLDENTED; /* tipo de mensagem inválido */ 

09778 } else if (call nr >= NR SYS CALLS) { /* verifica número da chamada */ 

09779 kprintf("'SYSTEM: illegal request %d from %d.\n", call nr,m.m source); 

09780 result = EBADREQUEST; /* tipo de mensagem inválido */ 

09781 

09782 else 1 

09783 result = (*call vec[call nrl])(&m); /* manipula a chamada de núcleo */ 


09784 F 
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09785 
09786 
09787 
09788 
09789 
09790 
09791 
09792 
09793 
09794 
09795 
09796 
09797 


09799 
09800 
09801 
09802 
09803 
09804 
09805 
09806 
09807 
09808 
09809 
09810 
09811 
09812 
09813 
09814 
09815 
09816 
09817 
09818 
09819 
09820 
09821 
09822 
09823 
09824 
09825 
09826 
09827 
09828 
09829 
09830 
09831 
09832 
09833 
09834 
09835 
09836 
09837 
09838 
09839 
09840 
09841 
09842 
09843 
09844 


PRIVATE void initialize(void) 


{ 


/* Envia uma resposta, a não ser que seja inibido por uma função de tratamento. Usa 
* a função de núcleo lock send() para evitar uma interrupção de chamada de sistema. 
* É sabido que o destino está bloqueado esperando por uma mensagem. 


*/ 
if (result != EDONTREPLY) 
m.m type = result; 


{ 


/* relata status da chamada */ 


if (OK != (s=lock_send(m.m_source, &m))) { 
kprintf("SYSTEM, reply to %d failed: %d\n", m.m source, s); 


} 


register struct priv *sp; 
inte is 


/* Inicializa ganchos de rotina de tratamento de IRQ. Marca ganchos como disponíveis. */ 
for (i=0; i<NR IRQ HOOKS; i++) { 


irq_hooks[i].proc_nr = NONE; 


} 


/* Inicializa todos os temporizadores de alarme para todos os processos. */ 
for (sp=BEG_PRIV_ADDR; sp < END_PRIV_ADDR; sp++) { 
tmr_inittimer(&(sp->s_alarm_timer)); 


} 


/* Inicializa vetor de chamada com rotina de tratamento padrão. Algumas chamadas de núcleo 
* podem ser desativadas ou inexistentes. Então, mapeia explicitamente chamadas conhecidas 
* para suas funções de tratamento. Isso é feito com uma macro que fornece um erro 
* de compilação, caso seja usado um número de chamada inválido. A ordem não é importante. 


*/ 


for (i=0; i<NR_SYS_CALLS; i++) { 


call_vec[i] = do_unused; 


} 


/* Gerenciamento de processos. 


map(SYS_FORK, do_fork); 
map(SYS_EXEC, do_exec); 
map(SYS_EXIT, do_exit); 
map(SYS_NICE, do_nice); 
map(SYS PRIVCTL, do_privctl); 
map(SYS TRACE, do trace); 


/* Tratamento de sinais. */ 
map(SYS KILL, do kill); 
map(SYS GETKSIG, do getksig); 
map(SYS ENDKSIG, do endksig); 
map(SYS SIGSEND, do sigsend); 


map(SYS SIGRETURN, do sigreturn); 


/* E/S de dispositivo. */ 
map(SYS IRQCTL, do irqct1); 
map(SYS DEVIO, do devio); 
map(SYS SDEVIO, do sdevio); 


* um processo criou um novo processo */ 

* atualiza processo após executar */ 

* limpeza após a saída do processo */ 

* configura a prioridade da escalonamento */ 
* controle de privilégios do sistema */ 

* solicita uma operação de rastreamento */ 


* faz um processo ser sinalizado */ 

* PM verifica existência de sinais pendentes */ 
* PM concluiu o processamento do sinal */ 

* inicia sinal estilo POSIX */ 

* retorno de sinal estilo POSIX */ 


* operações de controle de interrupção */ 
* inb, inw, inl, outb, outw, outl */ 
* phys_insb, 


insw, _outsb, _outsw */ 
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09845 
09846 
09847 
09848 
09849 
09850 
09851 
09852 
09853 
09854 
09855 
09856 
09857 
09858 
09859 
09860 
09861 
09862 
09863 
09864 
09865 
09866 
09867 


09869 
09870 
09871 
09872 
09873 
09874 
09875 
09876 
09877 
09878 
09879 
09880 
09881 
09882 
09883 
09884 
09885 
09886 
09887 
09888 
09889 
09890 
09891 
09892 
09893 
09894 


09896 
09897 
09898 
09899 
09900 
09901 
09902 
09903 
09904 


map(SYS VDEVIO, do vdevio); /* vetor com requisições de devio */ 

map(SYS INT86, do int86); /* chamadas da BIOS de modo real */ 

/* Gerenciamento de memória. */ 

map(SYS NEWMAP, do newmap) ; /* configura um mapa de memória de processo */ 
map(SYS SEGCTL, do segct1); /* adiciona segmento e obtém seletor */ 
map(SYS MEMSET, do memset); /* escreve na área de memória */ 

/* Cópia. */ 

map(SYS UMAP, do umap); /* mapeamento de endereço virtual para físico */ 
map(SYS VIRCOPY, do vircopy); /* usa endereçamento virtual puro */ 

map(SYS PHYSCOPY, do physcopy); * usa endereçamento físico */ 

map(SYS VIRVCOPY, do virvcopy); /* vetor com requisições de cópia */ 

map(SYS PHYSVCOPY, do physvcopy); /* vetor com requisições de cópia */ 

/* Funcionalidade de relógio. */ 

map(SYS TIMES, do times); /* obtém tempos de funcionamento e processo */ 
map(SYS SETALARM, do setalarm); /* programa um alarme síncrono */ 


/* Controle de sistema. */ 


map(SYS ABORT, do abort); /* aborta o MINIX */ 
map(SYS GETINFO, do getinfo); /* solicita informações de sistema */ 
} 
/* === ¥ 
* get_priv * 
AAAA EEN EAEE / 
PUBLIC int get_priv(rc, proc type) 
register struct proc *rc; /* novo ponteiro de processo (filho) */ 
int proc type; /* flag de processo de sistema ou de usuário */ 


{ 


/* Obtém uma estrutura de privilégio. Todos os processos de usuário compartilham a mesma 


* estrutura de privilégio. Os processos de sistema recebem uma estrutura própria. 


*/ 
register struct priv *sp; /* estrutura de privilégio */ 
if (proc type == SYS PROC) { /* encontra uma nova entrada */ 
for (sp = BEG PRIV ADDR; sp < END PRIV ADDR; ++sp) 
if (sp->s proc nr == NONE && sp->s id != USER PRIV ID) break; 
if (sp->s proc nr != NONE) return(ENOSPC) ; 
rc->p priv = sp; /* atribui nova entrada */ 
rc->p priv->s proc nr = proc nr(rc); /* configura associação */ 
rc->p priv->s flags = SYS PROC; /* marca como privilegiado */ 
} else { 
rc->p_priv = &priv[USER PRIV ID]; /* usa entrada compartilhada */ 
rc->p priv->s proc nr = INIT PROC NR; /* configura associação */ 
rc->p priv->s flags = 0; /* sem flags iniciais */ 
return(OK); 
} 
/* === ¥ 
* get_randomness * 
* === * / 


PUBLIC void get randomness (source) 

int source; 

{ 

/* Nas máquinas com RDTSC (instrução de leitura de contador de ciclos - pentium 

* e superiores), usa isso para aproveitar entropia bruta de alta resolução. Caso contrário, 
* usa o relógio de tempo real (resolução de tique). 
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09905 
09906 
09907 
09908 
09909 
09910 
09911 
09912 
09913 
09914 
09915 
09916 
09917 
09918 
09919 
09920 
09921 
09922 
09923 
09924 
09925 
09926 


09928 
09929 
09930 
09931 
09932 
09933 
09934 
09935 
09936 
09937 
09938 
09939 
09940 
09941 
09942 
09943 
09944 


09946 
09947 
09948 
09949 
09950 
09951 
09952 
09953 
09954 
09955 
09956 
09957 
09958 
09959 
09960 
09961 
09962 
09963 
09964 


* Infelizmente, este teste é de tempo de execução - não queremos nos incomodar com 


a compilação de diferentes núcleos para diferentes máquinas. 


Nas máquinas sem RDTSC, usamos read clock(). 


*/ 


i 


nt r_next; 


unsigned long tsc_high, tsc_low; 


source %= RANDOM_SOURCES; 
r_next= krandom.bin[source].r_next; 


i 


} 
} 


i 


f (machine.processor > 486) { 
read tsc(&tsc high, &tsc_low); 
krandom.bin[source].r buf[r next] = tsc low; 

else 1 
krandom.bin[source].r buf[r next] = read clock(); 


f (krandom.bin[source].r size < RANDOM ELEMENTS) { 
krandom.bin[source].r size ++; 


} 
krandom.bin[source].r_next = (r_next + 1 ) % RANDOM_ELEMENTS; 

} 

Jien eaa e a a a a 
x send_sig = 
A 

PUBLIC void send sig(proc nr, sig nr) 

int proc nr; /* processo de sistema a ser sinalizado */ 

int sig nr; /* sinal a ser enviado, de 1 a NSIG */ 

{ 


/* Notifica um processo de sistema a respeito de um sinal. Isso é simples. Basta 
* configurar o sinal que vai ser enviado no mapa de sinais pendentes e 


enviar uma notificação com SYSTEM de origem. 


*/ 


register struct proc *rp; 


rp = proc addr(proc nr); 
sigaddset(&priv(rp)->s sig pending, sig nr); 
lock notify(SYSTEM, proc nr); 

} 

/* === ¥ 
a cause sig ii 
kD=======D==>=>=>=>>=>=>>=>>=>=>>>>>=>>=>>=>>=>>>>=>=>=>=>>>>=>>=>>>=>>>>>>=>>=>>=>=>==>>=>>======= * / 

PUBLIC void cause sig(proc nr, sig nr) 

int proc nr; /* processo a ser sinalizado */ 

int sig nr; /* sinal a ser enviado, de 1 a NSIG */ 

{ 


/* Um processo de sistema quer enviar um sinal para um processo. Exemplos são: 


- HARDWARE querendo causar um SIGSEGV após uma exceção da CPU 
- TTY querendo causar SIGINT ao receber um DEL 
- FS querendo causar SIGPIPE para um pipe quebrado 


os sinais e garante que o PM os receba, enviando uma notificação. O processo que 


* está sendo sinalizado é bloqueado, enquanto o PM não tiver concluído todos os 


* 


* 


sinais para ele. Não podem existir condições de corrida 

entre as chamadas para esta função e as chamadas de sistema que 

processam sinais de núcleo pendentes. As funções relacionadas a sinais só 

são chamadas quando um processo de usuário causa uma exceção de CPU e a partir do 
nível de processo do núcleo, que executa até o final. 


* Os sinais são manipulados pelo envio de uma mensagem para o PM. Esta função manipula 
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09965 A 

09966 register struct proc *rp; 

09967 

09968 /* Verifica se o sinal já está pendente. Caso contrário, o processa. */ 


09969 rp = proc addr(proc nr); 
09970 if (! sigismember(&rp->p pending, sig nr)) 1 


09971 sigaddset(&rp->p pending, sig nr); 

09972 if (! Crp->p rts flags & SIGNALED)) 1 /* outro pendente */ 
09973 if Crp->p rts flags == 0) lock dequeue(rp); /* torna não pronto */ 
09974 rp->p rts flags |= SIGNALED | SIG PENDING; /* atualiza flags */ 
09975 send sig(PM PROC NR, SIGKSIG); 

09976 } 

09977 } 

09978 } 

09980 /* === Ý 
09981 i umap_local * 
09982 fEEDSSSSSSDSSDDSSSSDSESSS SSD SSSSSS SSIS SSI DES SS SSSSSsSE SSD SS / 


09983 PUBLIC phys bytes umap local(rp, seg, vir addr, bytes) 

09984 register struct proc *rp; /* ponteiro para entrada da tabela de proc do processo */ 
09985 int seg; /* segmento T, Dou S */ 

09986 vir bytes vir addr; /* endereço virtual em bytes dentro do seg */ 

09987 vir bytes bytes; /* nº de bytes a serem copiados */ 


09988 { 

09989 /* Calcula o endereço da memória física para determinado endereço virtual. */ 
09990 vir clicks vc; /* o endereço virtual em clicks */ 

09991 phys bytes pa; /* variáveis intermediárias como phys bytes */ 
09992 phys bytes seg base; 

09993 

09994 /* Se "seg' é D, poderia ser S e vice-versa. T significa realmente T. 

09995 * Se o endereço virtual cai na lacuna, ele causa um problema. No 

09996 * 8088 provavelmente é uma referência de pilha válida, pois os "erros de pilha” não 
09997 * são detectados pelo hardware. Nos 8088, a lacuna é chamada S e 

09998 * aceita, mas em outras máquinas ela é chamada D e rejeitada. 

09999 * O Atari ST se comporta como o 8088 a esse respeito. 

10000 */ 

10001 

10002 if (bytes <= 0) return( (phys bytes) 0); 

10003 if (vir addr + bytes <= vir addr) return 0; /* estouro */ 


10004 vc = (vir addr + bytes - 1) >> CLICK SHIFT; /* último click de dados */ 
10005 
10006 if (seg != T) 


10007 seg = (vc < rp->p memmap[D].mem vir + rp->p memmap[D] .mem Ten ? D : S); 
10008 

10009 if (Cvir addr>>CLICK SHIFT) >= rp->p memmap[seg].mem vir + 

10010 rp->p memmap[seg] .mem Ten) return(C (phys bytes) O ); 

10011 

10012 if (vc >= rp->p memmap[seg].mem vir + 

10013 rp->p memmap[seg] .mem Ten) return(C (phys bytes) O ); 

10014 

10015 seg base = (phys bytes) rp->p memmap[seg] .mem phys; 

10016 seg base = seg base << CLICK SHIFT; /* origem do segmento em bytes */ 


10017 pa = (phys bytes) vir addr; 

10018 pa -= rp->p memmap[seg].mem vir << CLICK SHIFT; 
10019 return(seg base + pa); 

10020 3 
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10022 
10023 
10024 
10025 
10026 
10027 
10028 
10029 
10030 
10031 
10032 
10033 
10034 
10035 
10036 
10037 
10038 
10039 
10040 
10041 
10042 


10044 
10045 
10046 
10047 
10048 
10049 
10050 
10051 
10052 
10053 
10054 
10055 
10056 
10057 
10058 
10059 
10060 
10061 
10062 
10063 
10064 
10065 
10066 


10068 
10069 
10070 
10071 
10072 
10073 
10074 
10075 
10076 
10077 
10078 
10079 
10080 
10081 


PUBLIC phys bytes umap remote(rp, seg, vir addr, bytes) 


register struct proc *rp; 
int seg; 

vir bytes vir addr; 

vir bytes bytes; 

{ 


/* ponteiro para entrada da tabela de proc do processo */ 
/* índice de segmento remoto */ 

/* endereço virtual em bytes dentro do seg */ 

/* n° de bytes a serem copiados */ 


/* Calcula o endereço da memória física para determinado endereço virtual. */ 


struct far_mem *fm; 


if (bytes <= 0) return( (phys_bytes) 0); 
if (seg < 0 || seg >= NR_REMOTE_SEGS) return( (phys_bytes) 0); 


fm = &rp->p_priv->s_farmem[seg]; 
if (! fm->in_use) return( (phys_bytes) 0); 
if (vir addr + bytes > fm->mem_len) return( (phys_bytes) 0); 


return(fm->mem phys + (phys bytes) vir addr); 


PUBLIC phys bytes umap bios(rp, vir addr, bytes) 


register struct proc *rp; 
vir bytes vir addr; 

vir bytes bytes; 

{ 


/* ponteiro para entrada da tabela de proc do processo */ 
/* endereço virtual em segmento da BIOS */ 
/* nº de bytes a serem copiados */ 


/* Calcula o endereço da memória física na BIOS. Nota: atualmente, o endereço zero 
* da BIOS (o primeiro vetor de interrupção da BIOS) não é considerado como 


* erro aqui, mas como o endereço físico também será zero, a 


* função que fez a chamada pensará que ocorreu um erro. Isso não é problema, 
* pois ninguém usa o primeiro vetor de interrupção da BIOS. 


*/ 


/* Verifica todos os intervalos aceitáveis. */ 

if (vir addr >= BIOS MEM BEGIN && vir_addr + bytes <= BIOS MEM END) 
return (phys bytes) vir addr; 

else if (vir addr >= BASE MEM TOP && vir addr + bytes <= UPPER MEM END) 
return (phys bytes) vir addr; 

kprintfC'warning, error in umap bios, virtual address 0x%x\n", vir addr); 


return 0; 


PUBLIC int virtual copy(src addr, dst addr, bytes) 


struct vir addr *src addr; 
struct vir addr *dst addr; 
vir bytes bytes; 

{ 


/* endereço virtual da origem */ 
/* endereço virtual do destino */ 
/* n° de bytes a copiar */ 


/* Copia bytes do endereço virtual src_addr no endereço virtual dst_addr. 
* Os endereços virtuais podem estar em ABS, LOCAL SEG, REMOTE SEG ou BIOS SEG. 


*/ 


struct vir_addr *vir_addr[2]; 


phys_bytes phys_addr[2]; 
int seg_index; 


/* endereço virtual de origem e destino */ 
/* origem e destino absoluto */ 


708 SISTEMAS OPERACIONAIS 


10082 int i? 


10083 

10084 /* Verifica contador de cópia. */ 

10085 if (bytes <= 0) return(EDOM); 

10086 

10087 /* Verifica e realiza o mapeamento de end. virtuais em end. físicos. */ 


10088 vir_addr[_SRC_] = src_addr; 
10089 vir_addr[_DST_] = dst_addr; 
10090 for (i=_SRC_; i<=_DST_; i++) { 


10091 

10092 /* Obtém endereço físico. */ 

10093 switch((vir addr[i]->segment & SEGMENT TYPE) 1 

10094 case LOCAL SEG: 

10095 seg index = vir addr[i]->segment & SEGMENT INDEX; 

10096 phys addr [i] = umap lTocal( proc addr(vir addr[i]->proc nr), 
10097 seg index, vir addr[i]->offset, bytes ); 

10098 break; 

10099 case REMOTE SEG: 

10100 seg index = vir addr[i]->segment & SEGMENT INDEX; 

10101 phys addr [1] = umap remote( proc addr(vir addr[i]->proc nr), 
10102 seg index, vir addr[i]->offset, bytes ); 

10103 break; 

10104 case BIOS SEG: 

10105 phys addr[1] = umap bios( proc addr(vir addr[il]->proc nr), 
10106 vir addr[i]->offset, bytes ); 

10107 break; 

10108 case PHYS SEG: 

10109 phys addr[1] = vir addr[i]->offset; 

10110 break; 

10111 default: 

10112 return(EINVAL); 

10113 

10114 

10115 /* Verifica se o mapeamento teve êxito. */ 

10116 if Cphys addr[i] <= 0 && vir addr[i]->segment != PHYS SEG) 
10117 return(EFAULT); 

10118 } 

10119 

10120 /* Agora, copia bytes entre endereços físicos. */ 


10121 phys_copy(phys_addr[_SRC_], phys_addr[_DST_], (phys_bytes) bytes); 
10122 return(OK) ; 
10123 } 


DO ssa Do O O O O HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH O DD O O O O DO OO OO O O 
kernel/system/do setalarm.c 
DO sn oo o SS a DS DO H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH O DD O HHH O DO O OO O DD 


10200 /* A chamada de núcleo implementada neste arquivo: 


10201 *  m type: SYS SETALARM 

10202 $ 

10203 * Os parâmetros desta chamada de núcleo são: 

10204 i m2_11: ALRM_EXP_TIME (tempo de expiração do alarme) 

10205 * m2 i2: ALRM ABS TIME (o tempo de expiração é absoluta?) 

10206 * m2 11: ALRM TIME LEFT (retorna os segundos restantes do anterior) 
10207 */ 

10208 


10209 &include "../system.h"” 
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10210 
10211 
10212 
10213 
10214 
10215 
10216 
10217 
10218 
10219 
10220 
10221 
10222 
10223 
10224 
10225 
10226 
10227 
10228 
10229 
10230 
10231 
10232 
10233 
10234 
10235 
10236 
10237 
10238 
10239 
10240 
10241 
10242 
10243 
10244 
10245 
10246 
10247 
10248 
10249 
10250 
10251 
10252 
10253 
10254 
10255 
10256 
10257 


10259 
10260 
10261 
10262 
10263 
10264 
10265 
10266 
10267 
10268 
10269 


#if USE SETALARM 


FORWARD | PROTOTYPE( void cause alarm, (timer t *tp) ); 


/* 


PUBLIC int do setalarm(m ptr) 
message *m ptr; /* ponteiro para mensagem de requisição */ 
{ 


/* Um processo solicita um alarme síncrono ou quer cancelar seu alarme. */ 


register struct proc *rp; /* ponteiro para processo solicitante */ 

int proc nr; /* que processo quer o alarme */ 

long exp time; /* tempo de expiração deste alarme */ 

int use abs time; /* usa tempo absoluto ou relativo */ 

timer t *tp; /* a estrutura de temporizadores do processo */ 

clock t uptime; /* lugar reservado para tempo de funcionamento corrente */ 


/* Extrai parâmetros compartilhados da mensagem de requisição. */ 


exp time = m ptr->ALRM EXP TIME; /* tempo de expiração do alarme */ 
use abs time = m ptr->ALRM ABS TIME; /* flag para tempo absoluto */ 
proc nr =m ptr->m source; /* processo a interromper posteriormente */ 


rp = proc addr(proc nr); 
if (! CprivCrp)->s flags & SYS PROC)) return(EPERM); 


/* Obtém a estrutura de temporizadores e configura os parâmetros desse alarme. */ 
tp = &Cpriv(rp)->s alarm timer); 

tmr arg(tp)->ta int = proc nr; 

tp->tmr func = cause alarm; 


/* Retorna os tiques restantes no alarme anterior. */ 

uptime = get uptime); 

if (Ctp->tmr exp time != TMR NEVER) && (uptime < tp->tmr exp time) ) { 
m ptr->ALRM TIME LEFT = (tp->tmr exp time - uptime); 

} else { 
m_ptr->ALRM_TIME_LEFT = 0; 

} 


/* Finalmente, (re)configura o temporizador, dependendo do tempo de expiração. */ 
if (exp time == 0) { 

reset_timer(tp); 
} else { 

tp->tmr exp time = (use abs time) ? exp time : exp time + get_uptime(); 

set timer(tp, tp->tmr exp time, tp->tmr func); 


return(OK); 


ARAA E SE + / 
PRIVATE void cause alarm(tp) 

timer t *tp; 

{ 


/* Rotina chamada se um temporizador expira e o processo solicitou um 
* alarme síncrono. O número do processo é armazenado no argumento de temporizador "ta int”. 
* Notifica esse processo com uma mensagem de notificação de CLOCK. 
74 


int proc nr = tmr arg(tp)->ta int; /* obtém o número do processo */ 
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10270 
10271 


10273 


lock_notify(CLOCK, proc nr); 


} 


/* notifica o processo */ 


#endif /* USE_SETALARM */ 


HHHEHEHHHHHHH+ HHHH HHH HH H+H HH HH HH H+H HHHH HHHH ++ 
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AAA ++ 


10300 
10301 
10302 
10303 
10304 
10305 
10306 
10307 
10308 
10309 
10310 
10311 
10312 
10313 
10314 
10315 
10316 
10317 
10318 
10319 
10320 
10321 
10322 
10323 
10324 
10325 
10326 
10327 
10328 
10329 
10330 
10331 
10332 
10333 
10334 
10335 
10336 
10337 
10338 
10339 
10340 
10341 
10342 
10343 
10344 
10345 
10346 
10347 
10348 


/* A chamada de núcleo implementada neste arquivo: 


* m_type: SYS EXEC 
* Os parâmetros desta chamada de núcleo são: 
E mi il: PR PROC NR (processo que fez a chamada de exec) 
x ml pl: PR STACK PTR (novo ponteiro de pilha) 
* ml p2: PR NAME PTR (ponteiro para nome do programa) 
* ml p3: PR IP PTR (novo ponteiro de instrução) 
*/ 
ginclude "../system.h"” 
#include <string.h> 
#include <signal.h> 


#if USE_EXEC 


PUBLIC int do_exec(m_ptr) 


register 


{ 


/* Manipula sys_exec(). Um processo executou uma operação EXEC bem-sucedida. O emenda. 


message *m_ptr; /* ponteiro para mensagem de requisição */ 


register struct proc *rp; 

reg_t sp; /* new sp */ 
phys bytes phys name; 

char *np; 


rp = proc addr(m ptr->PR PROC NR); 

sp = (reg t) m ptr->PR STACK PTR; 

rp->p reg.sp = sp; /* configura o ponteiro de pilha */ 
phys memset(vir2phys(&rp->p Tdt[EXTRA LDT INDEX7), O, 


(CLDT SIZE - EXTRA LDT INDEX) * sizeof(rp->p Tdt[01)); 


rp->p reg.pc = (reg t) m ptr->PR IP PTR; /* configura pc */ 
rp->p rts flags &= “RECEIVING; /* o OM não responde à chamada de EXEC */ 
if Crp->p rts flags == 0) lock enqueue(rp); 


/* Salva nome do comando para depuração, saída de ps(1) etc. */ 
phys name = numap local(m ptr->m source, (vir bytes) m ptr->PR NAME PTR, 


(vir bytes) P NAME LEN - 1); 


if (phys name != 0) { 


+ else 


phys copy(phys name, vir2phys(rp->p name), (phys bytes) P NAME LEN - 1); 
for (np = rp->p name; (*np & BYTE) >= 
*np = 0; /* marca o final */ 


; np++) O 
{ 


strncpy(rp->p name, "<unset>", P_NAME_LEN); 


return(0K); 


} 


#endif /* USE_EXEC */ 


*/ 
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HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HH HH HHHH HHHH HHHH H+H HHHH HHHH HHHH HH+H+H+H+H+H+H+H+H+ 


10400 
10401 
10402 
10403 
10404 
10405 
10406 
10407 
10408 
10409 
10410 
10411 
10412 
10413 
10414 
10415 
10416 
10417 
10418 
10419 
10420 
10421 
10422 
10423 
10424 
10425 
10426 
10427 
10428 
10429 
10430 
10431 
10432 
10433 
10434 
10435 
10436 
10437 
10438 
10439 
10440 
10441 
10442 
10443 
10444 
10445 
10446 
10447 
10448 
10449 
10450 
10451 
10452 
10453 
10454 


/* Este arquivo contém a tarefa de relógio, a qual manipula funções relacionadas ao tempo. 
* Os eventos importantes manipulados por CLOCK incluem configurar e 
* monitorar temporizadores de alarme e decidir sobre o momento de (re)escalonar processos. 
O CLOCK oferece uma interface direta para processos do núcleo. Os serviços de sistema 
podem acessar seus serviços por meio de chamadas de sistema, como sys setalarm(). 
* Assim, a tarefa CLOCK fica oculta do mundo exterior. 


Alterações: 
08 de outubro de 2005 reordenação e edição de comentários (A. S. Woodhull) 
* 18 de março de 2004 interface de relógio movida para a tarefa SYSTEM (Jorrit N. Herder) 
x 30 de setembro de 2004 documentação do código-fonte atualizada (Jorrit N. Herder) 
24 de setembro de 2004 temporizadores de alarme reprojetados (Jorrit N. Herder) 


* A função do_clocktick() é ativada pela rotina de tratamento de interrupção 
* do relógio, quando um temporizador cão de guarda ou um processo precisa ser escalonado. 


Além do ponto de entrada principal de clock_task(), que inicia o 
* laço principal, existem vários outros pontos de entrada secundários: 


* clock stop: chamada apenas antes do desligamento do MINIX 

* get uptime: obtém o tempo real desde a inicialização, em tiques de relógio 
* set timer: configura um temporizador de sentinela (+) 

* reset timer: reconfigura um temporizador de sentinela (+) 

* read clock: lê o contador de canal O do temporizador 8253A 


(+) A tarefa CLOCK monitora os temporizadores de cão de guarda do núcleo inteiro. 

* As funções de cão de guarda de temporizadores expirados são executadas em do clocktick(). 
* É fundamental que as funções de cão de guarda não sejam bloqueadas, senão, a tarefa 

* CLOCK pode ser bloqueada. Não envia uma mensagem (com send()) quando o receptor não 

* estiver esperando. Em vez disso, deve ser usada notify(D, que retorna sempre. 


EA 


tinclude "kernel.h” 
tinclude "proc.h" 
tinclude <signal.h> 
tinclude <minix/com.h> 


/* Protótipo de função para funções PRIVATE. */ 

FORWARD | PROTOTYPE( void init clock, (void) ); 

FORWARD | PROTOTYPE( int clock handler, (irq hook t *hook) ); 
FORWARD | PROTOTYPE( int do clocktick, (message *m ptr) ); 


/* Parâmetros de relógio */ 
define COUNTER FREQ (2*TIMER FREQ) /* frequência do contador usando onda quadrada */ 
Hdefine LATCH COUNT 0x00  /* cc00xxxx, c = canal, x = qualquer um */ 
#define SQUARE WAVE 0x36 /* ccaammmb, a = acesso, m = modo, b = BCD */ 

/* 11x11, 11 = LSB então MSB, x11 = onda quadrada */ 
define TIMER COUNT ((Cunsigned) (TIMER FREQ/HZ)) /* valor inicial do contador */ 
tdefine TIMER FREQ 1193182L /* frequência do relógio para temporizador em PC e AT */ 


tdefine CLOCK ACK BIT 0x80 /* bit de reconhecimento de interrupção de clock do PS/2 */ 


/* A fila de temporizadores de CLOCK. As funções em <timers.h> operam nisso. 
* Cada processo de sistema possui um único temporizador de alarme síncrono. Se outras 
* partes do núc;ep quiserem usar mais temporizadores, elas devem declarar suas próprias 
* estruturas de temporizadores persistentes (estáticas), as quais podem ser passadas 
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10455 
10456 
10457 
10458 
10459 


10460 
10461 


10462 
10463 
10464 
10465 
10466 
10467 
10468 
10469 
10470 
10471 
10472 
10473 
10474 
10475 
10476 
10477 
10478 
10479 
10480 
10481 
10482 
10483 
10484 
10485 
10486 
10487 
10488 
10489 
10490 
10491 
10492 


10494 
10495 
10496 
10497 
10498 
10499 
10500 
10501 
10502 
10503 
10504 
10505 
10506 
10507 
10508 
10509 
10510 
10511 
10512 
10513 
10514 


* para o núcleo via (re)set timer(. 
* Quando um temporizador expira, sua função de cão de guarda é executada pela tarefa CLOCK. 


*/ 


PRIVATE timer t *clock timers; /* fila de temporizadores de CLOCK */ 
PRIVATE clock t next timeout; /* tempo real em que o próximo temporizador 
expira */ 


/* O tempo é incrementado pela rotina de tratamento de interrupção em cada tique de 
relógio. */ 

PRIVATE clock t realtime; /* clock de tempo real */ 

PRIVATE irq hook t clock hook; /* gancho da rotina de tratamento de interrupção */ 


PUBLIC void clock task) 
{ 


/* Programa principal da tarefa de relógio. Se a chamada não for por HARD_INT, é um erro. 


E 


message m; /* buffer de mensagem para entrada e saída */ 
int result; /* resultado retornado pela rotina de tratamento */ 
init clock); /* inicializa a tarefa de relógio */ 


/* Laço principal da tarefa de relógio. Recebe o trabalho e o processa. Nunca responde. */ 
while (TRUE) 1 


/* Recebe uma mensagem. */ 
receive(ANY, &m); 


/* Trata da requisição. Somente tiques de relógio são esperados. */ 
switch (m.m type) É 
case HARD INT: 


result = do clocktick(&m); /* manipula tique de relógio */ 
break; 
default: /* tipo de requisição inválida */ 


kprintfC"CLOCK: illegal request %d from %d.Nn", m.m type,m.m source); 


PRIVATE int do clocktick(m ptr) 
message *m ptr; /* ponteiro para mensagem de requisição */ 
{ 


/* Apesar de seu nome, esta rotina não é chamada em cada tique de relógio. Ela 


*/ 


é chamada apenas nos tiques de relógio em que há muito trabalho a ser feito. 


/* Processo usou um quantum inteiro. A rotina de tratamento de interrupção armazenou esse 
* processo em "prev ptr'. Primeiro, certifica-se de que o processo não está nas filas 
* de escalonamento. Então, anuncia que o processo está pronto novamente. Como ele não 
* tem mais tempo restante, recebe novo quantum e é inserido no lugar correto nas 
* filas. Como um efeito colateral, um novo processo é escalonado. 


*/ 
if (prev ptr->p ticks left <= 0 && privCprev ptr)->s flags & PREEMPTIBLE) { 
lock dequeueC(prev ptr); /* o retira das filas */ 
lock enqueue(prev ptr); /* e reinsere novamente */ 
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10515 
10516 
10517 
10518 
10519 
10520 
10521 
10522 
10523 
10524 


10526 
10527 
10528 
10529 
10530 
10531 
10532 
10533 
10534 
10535 


10536 
10537 
10538 


10539 
10540 


10542 
10543 
10544 
10545 
10546 
10547 
10548 
10549 
10550 
10551 


10553 
10554 
10555 
10556 
10557 
10558 
10559 
10560 
10561 
10562 
10563 
10564 
10565 
10566 
10567 
10568 
10569 
10570 
10571 
10572 
10573 
10574 


P 
{ 


P 
i 


{ 


/* 


/* Verifica se um temporizador expirou e executa sua função cão de guarda. */ 

if (next timeout <= realtime) { 
tmrs_exptimers(&clock_timers, realtime, NULL); 
next_timeout = clock_timers == NULL ? 

TMR_NEVER : clock_timers->tmr_exp_time; 

} 

/* Inibe o envio de uma resposta. */ 

return (EDONTREPLY) ; 

init clock * 

X === * / 

RIVATE void init clockO 

/* Inicializa o gancho de interrupção de CLOCK. */ 

clock hook.proc nr = CLOCK; 

/* Inicializa o canal O do temporizador 8253A como, por exemplo, 60 Hz. */ 

outb(TIMER MODE, SQUARE WAVE); /* configura o temporizador para executar 


continuamente */ 
outb(TIMERO, TIMER COUNT); 


/* carrega o byte inferior do temporizador */ 


outb(TIMERO, TIMER COUNT >> 8); /* carrega o byte superior do temporizador */ 
put irq handler(&clock hook, CLOCK TIRQ, clock handler);/* registra a rotina de 


tratamento */ 
enable irq(&clock hook) ; 


PUBLIC void clock stop) 
{ 
/* 


Reconfigura o relógio com a taxa da BIOS. (Para reinicialização) */ 
outb(TIMER_MODE, 0x36); 
outb(TIMERO, 0); 
outb(TIMERO, 0); 


RIVATE int clock_handler (hook) 
rq hook t *hook; 


/* pronto para interrupções de relógio */ 


Isto executa em cada tique de relógio(isto é, sempre que o chip temporizador gera 


* uma interrupção). Realiza pouco trabalho para que a tarefa de relógio não tenha que ser 


chamada em cada tique. A tarefa de relógio é chamada quando: 


* (1) a escalonamento do quantum do processo em execução expirou ou 


é (2) um temporizador expirou e a função cão de guarda deve ser executada. 


Muitas variáveis globais e estáticas são acessadas aqui. A segurança disso 


* deve ser justificada. Todo código de escalonamento e passagem de mensagem adquire uma 
* trava desativando as interrupções temporariamente; portanto, nenhum conflito com chamadas 


do nível da tarefa pode ocorrer. Além disso, as interrupções não são reentrantes, a 
rotina de tratamento de interrupção não pode ser incomodada por outras interrupções. 


* As variáveis que são atualizadas na rotina de tratamento de interrupção do relógio: 


lost ticks: 


Tiques de relógio contados fora da tarefa de relógio. Usado, 


por exemplo, 
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10575 ii quando o monitor de inicialização processa uma interrupção de modo real. 
10576 ¥ tempo real: 

10577 x O tempo de corrente é incrementado com todos os tiques pendentes. 

10578 Ei proc ptr, bill ptr: 

10579 $ Eles são usados para contabilidade. Não importa se proc.c 

10580 $ os está alterando, desde que sejam sempre ponteiros válidos, 

10581 $ pois na pior das hipóteses, o processo anterior seria cobrado. 

10582 +, 

10583 register unsigned ticks; 

10584 


10585 /* Reconhece a interrupção de relógio do PS/2. */ 

10586 if (machine.ps mca) outb(PORT B, inb(PORT B) | CLOCK ACK BIT); 
10587 

10588 /* Obtém o número de ticks e atualiza o tempo real. */ 

10589 ticks = lost ticks + 1; 

10590 lost ticks = 0; 


10591 realtime += ticks; 

10592 

10593 /* Atualiza contabilização de tempo de usuário e de sistema. Se for processo de usuário 
10594 * que executa então credita tempo de usuário ao seu próprio campo tempo de usuário, 
10595 * senão credita o tempo de sistema ao processo do usuário corrente. Assim, o tempo 
10596 * de usuário não contabilizado é o tempo de sistema do processo de usuário. 

10597 */ 

10598 proc ptr->p user time += ticks; 

10599 if CprivCproc ptr)->s flags & PREEMPTIBLE) { 

10600 proc ptr->p ticks left -= ticks; 

10601 } 

10602 if (! Cpriv(proc_ptr)->s_flags & BILLABLE)) { 

10603 bill_ptr->p_sys_time += ticks; 

10604 bill_ptr->p_ticks_left -= ticks; 

10605 } 

10606 

10607 /* Verifica se do_clocktick() deve ser chamada. Feito para alarmes e escalonamento. 
10608 * Alguns processos, como as tarefas do núcleo, não podem passar por preempção. 
10609 EX 

10610 if (Cnext timeout <= realtime) || (proc ptr->p ticks Teft <= 0)) 1 

10611 prev ptr = proc ptr; /* armazena o processo em execução */ 
10612 lock notify(HARDWARE, CLOCK); /* envia notificação */ 

10613 

10614 return(1); /* reativa as interrupções */ 

10615 + 

10617 fE=s=D==>=>>=>>=>>>=>>=>*=>>>>=>>>=> "DE -===——=———===—>=—>==—==>===—— == === * 

10618 3 get_uptime hi 

10619 dns ==ss=ES===DSFESs- SEE A 
10620 PUBLIC clock t get uptime() 

10621 { 


10622 /* Obtém e retorna o tempo de funcionamento do relógio corrente, em tiques. */ 
10623 return(realtime); 


10624 } 

10626 

10627 

10628 

10629 PUBLIC void set timer(tp, exp time, watchdog) 

10630 struct timer “tp; /* ponteiro para estrutura de temporizadores */ 
10631 clock t exp time; /* tempo real da expiração */ 

10632 tmr func t watchdog; /* cão de guarda a ser chamado */ 

10633 { 


10634 /* Insere o novo temporizador na lista de temporizadores ativos. Sempre atualiza o 


Apêndice B e O Cóbigo-FONTE DO MINIX 715 


* próximo tempo limite, configurando-o na frente da lista ativa. 


*/ 


tmrs_settimer(&clock_timers, tp, exp_time, watchdog, NULL); 
next_timeout = clock_timers->tmr_exp_time; 


PUBLIC void reset timer(tp) 
struct timer *tp; /* ponteiro para estrutura de temporizadores */ 


{ 


/* O temporizador apontado por "tp' não é mais necessário. Remove-o das 
* listas ativa e expirada. Sempre atualiza o próximo tempo limite, configurando-o 
* na frente da lista ativa. 


EA 


tmrs clrtimer(&clock timers, tp, NULL); 
next timeout = (clock timers == NULL) ? 


PUBLIC unsigned To 


{ 


TMR_NEVER : clock_timers->tmr_exp_time; 


ng read clock() 


/* Lê o contador do canal O do temporizador 8253A. Esse contador conta 
* para baixo a uma velocidade de TIMER FREQ e reinicia em TIMER COUNT-1, quando 


chega 
* chega 


*/ 


a zero. Uma interrupção de hardware (tique de relógio) ocorre quando o contador 
a zero e reinicia seu ciclo. 


unsigned count; 


outb(TIMER MODE, LATCH COUNT); 
count = inb(TIMERO); 


count 


return 


|= Cinb(TIMERO) << 8); 


count; 


AAA ++ 


drivers/drivers.h 


AAA ++ 


10700 
10701 
10702 
10703 
10704 
10705 
10706 
10707 
10708 
10709 
10710 
10711 
10712 
10713 
10714 


/* Este é o cabeçalho mestre de todos os drivers de dispositivo. Ele inclui alguns outros 
ç p g 
* arquivos e define as principais constantes. 


#define _POSIX_SOURCE 1 /* diz aos cabeçalhos para incluírem material do POSIX */ 
#define _MINIX 1 /* diz aos cabeçalhos para incluírem material do MINIX */ 
tdefine SYSTEM 1 /* obtém número de erro negativo em <errno.h> */ 

/* O que segue é básico, todos os arquivos *.c os obtêm automaticamente. */ 

tinclude <minix/config.h> /* DEVE ser o primeiro */ 

tinclude <ansi.h> /* DEVE ser o segundo */ 

tinclude <minix/type.h> 


tinclude 
tinclude 
tinclude 
tinclude 


<minix/com.h> 
<minix/dmap.h> 
<minix/calinr.h> 
<sys/types.h> 
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10715 &include <minix/const.h> 
10716 &include <minix/devio.h> 
10717 #include <minix/syslib.h> 
10718 &include <minix/sysutil.h> 
10719 &include <minix/bitmap.h> 


10720 

10721 &include <ibm/interrupt.h> /* vetores de IRQ e portas diversas */ 
10722 include <ibm/bios.h> /* números de índice da BIOS */ 

10723 #include <ibm/ports.h> /* Portas conhecidas */ 

10724 


10725 #include <string.h> 
10726 #include <signal.h> 
10727 #include <stdlib.h> 
10728 #include <limits.h> 
10729 #include <stddef.h> 
10730 #include <errno.h> 
10731 #include <unistd.h> 
10732 


HHHHHEHHHHHHHH HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH H+ HHH +HH+H+H+H+H+H+H+H+H++H++++ 
drivers/libdriver/driver.h 
DO spa Do o O O O OD O HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH H+ O O DO OO OD O O 


10800 /* Tipos e constantes compartilhados entre o código de driver de dispositivo genérico e 


10801 * dependente de dispositivo. 

10802 */ 

10803 

10804 #define _POSIX_SOURCE I /* diz aos cabeçalhos para incluírem material do POSIX */ 
10805 #define _MINIX 1 /* diz aos cabeçalhos para incluírem material do MINIX */ 
10806 #define SYSTEM 1 /* obtém número de erro negativo em <errno.h> */ 

10807 

10808 /* O que segue é básico, todos os arquivos *.c os obtêm automaticamente. */ 

10809 #include <minix/config.h> /* DEVE ser o primeiro */ 

10810 &include <ansi.h> /* DEVE ser o segundo */ 


10811 #include <minix/type.h> 
10812 &include <minix/ipc.h> 

10813 &include <minix/com.h> 

10814 &include <minix/callnr.h> 
10815 #include <sys/types.h> 

10816 #include <minix/const.h> 
10817 #include <minix/syslib.h> 
10818 #include <minix/sysutil.h> 
10819 

10820 #include <string.h> 

10821 #include <limits.h> 

10822 #include <stddef.h> 

10823 #include <errno.h> 

10824 

10825 #include <minix/partition.h> 
10826 #include <minix/u64.h> 

10827 

10828 /* Informações sobre e pontos de entrada no código dependente de dispositivo. */ 
10829 struct driver { 


10830 - PROTOTYPE( char *(*dr_name), (void) ); 

10831 - PROTOTYPEC int (“dr open), (struct driver *dp, message *m_ptr) ); 
10832 - PROTOTYPEC int (“dr close), (struct driver *dp, message *m ptr) ); 
10833 - PROTOTYPEC int (“dr ioct1l), (struct driver *dp, message *m ptr) ); 


10834 - PROTOTYPE( struct device *(*dr prepare), (int device) ); 
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10835 
10836 
10837 
10838 
10839 
10840 
10841 
10842 
10843 
10844 
10845 
10846 
10847 
10848 
10849 
10850 
10851 
10852 
10853 
10854 
10855 
10856 
10857 
10858 
10859 
10860 
10861 
10862 
10863 
10864 
10865 
10866 
10867 
10868 
10869 
10870 
10871 
10872 
10873 
10874 
10875 
10876 
10877 
10878 
10879 
10880 
10881 
10882 
10883 
10884 
10885 
10886 
10887 
10888 
10889 
10890 


- PROTOTYPEC int (“dr transfer), (int proc nr, int opcode, off t position, 
iovec t *iov, unsigned nr reg) ); 
- PROTOTYPE( void (*dr cleanup), (void) ); 
- PROTOTYPE( void (*dr geometry), (struct partition *entry) ); 
- PROTOTYPE( void (*dr signal), (struct driver *dp, message *m ptr) ); 
- PROTOTYPE( void (*dr alarm), (struct driver *dp, message *m ptr) ); 
- PROTOTYPE( int (*dr cancel), (struct driver “dp, message *m ptr) ); 
- PROTOTYPEC int (“dr select), (struct driver *dp, message *m ptr) ); 
- PROTOTYPEC int (“dr other), (struct driver *dp, message *m ptr) ); 
- PROTOTYPEC int (“dr hw int), (struct driver *dp, message *m ptr) ); 
J}; 


#if (CHIP == INTEL) 


/* Número de bytes em que você pode usar DMA antes de atingir um limite de 64K: */ 
#define dma_bytes_left(phys) N 
(Cunsigned) (sizeof(int) == 2 ? O : 0x10000) - (unsigned) ((phys) & OxFFFF)) 


gendif /* CHIP == INTEL */ 
/* Base e tamanho de uma partição em bytes. */ 
struct device { 

u64_t dv_base; 

u64 t dv size; 


3; 
gdefine NIL DEV ((struct device *) 0) 


/* Funções definidas por driver.c: */ 

- PROTOTYPE( void driver task, (struct driver *dr) ); 

“ PROTOTYPE( char *no name, (void) ); 

- PROTOTYPEC int do nop, (struct driver *dp, message *m ptr) ); 

- PROTOTYPE( struct device *nop prepare, (int device) ); 

- PROTOTYPE( void nop cleanup, (void) ); 

- PROTOTYPE( void nop task, (void) ); 

- PROTOTYPE( void nop signal, (struct driver *dp, message *m ptr) ); 
- PROTOTYPE( void nop alarm, (struct driver *dp, message *m ptr) ); 
- PROTOTYPE( int nop cancel, (struct driver *dp, message *m ptr) ); 
- PROTOTYPE( int nop select, (struct driver *dp, message *m ptr) ); 
- PROTOTYPE( int do diocnt1, (struct driver *dp, message *m ptr) ); 


/* Parâmetros da unidade de disco. */ 


define SECTOR SIZE 512 /* tamanho do setor físico em bytes */ 
ádefine SECTOR SHIFT 9 /* para divisão */ 
tdefine SECTOR MASK 511 /* e resto */ 


/* Tamanho do buffer de DMA em bytes. */ 
#define USE EXTRA DMA BUF O | /* normalmente, desnecessário */ 
#define DMA BUF SIZE (DMA SECTORS * SECTOR SIZE) 


#if (CHIP == INTEL) 


extern u8 t *tmp buf; /* o buffer de DMA */ 
telse 

extern u8 t tmp bufl]; /* o buffer de DMA */ 
#endif 


extern phys_bytes tmp_phys; /* endereço físico do buffer de DMA */ 
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drivers/libdriver/drvlib.h 


HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HHH HH HHHH HHHH HHHH H+H HHHH HHHH HHHH HH+H+H+H+H+H+H+H+H+ 


10900 
10901 
10902 
10903 
10904 
10905 
10906 
10907 
10908 
10909 
10910 
10911 
10912 
10913 
10914 
10915 
10916 
10917 
10918 
10919 
10920 
10921 
10922 
10923 
10924 
10925 
10926 


/* Definições de driver de dispositivo IBM Autor: Kees J. Bot 
i 7 de dezembro de 1995 
A 


#include <ibm/partition.h> 
- PROTOTYPE( void partition, (struct driver *dr, int device, int style, int atapi) ); 


/* layout da tabela de parâmetros da BIOS. */ 

#define bp_cylinders(t) C* (ul6 t *) C&Ct) [01)) 
tdefine bp heads(t) (* (u8 t *)  (&(t)[2])) 
gdefine bp reduced wr(t) CŒ (ul6 t *) C&Ct)[31)) 
gdefine bp precomp(t) (* (ul6 t *) (&Ct)[5])) 
tdefine bp max ecc(t) C (u8 t *)  (&C)[7])) 
#define bp ctIbytect) C (u8 t+) C&Ct)[81)) 
gdefine bp landingzone(t) C (ul6 t *) C&Ct) [121)) 
tdefine bp sectors(t) CŒ (u8 t *)  (&Ct) 141) 


/* Diversos. */ 

#define DEV PER DRIVE (1 + NR PARTITIONS) 
#define MINOR tO 64 

gdefine MINOR ro 120 

ádefine MINOR dO0p0s0 128 

ádefine MINOR fdopo (28<<2) 


tdefine P FLOPPY 0 
tdefine P PRIMARY 1 
#define P SUB 2 


AAA ++ 


drivers/libdriver/driver.c 
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11000 
11001 
11002 
11003 
11004 
11005 
11006 
11007 
11008 
11009 
11010 
11011 
11012 
11013 
11014 
11015 
11016 
11017 
11018 
11019 


/* Este arquivo contém a interface de driver de dispositivo independente de dispositivo. 


* Alterações: 

* 25 de julho de 2005 tipo SYS_SIG adicionado para sinais (Jorrit N. Herder) 

* 15 de setembro de 2004 tipo SYN ALARM adicionado para tempos limites (Jorrit N. Herder) 
23 de julho de 2004 dependência do núcleo removidas (Jorrit N. Herder) 

* 02 de abril de 1992 construído a partir de AT wini e driver de disquete (Kees J. Bot) 


Os drivers suportam as seguintes operações (usando o formato de mensagem m2): 


+ m type DEVICE PROC NR COUNT POSITION ADRRESS 


| | | 
dp |as 4===——=——— +====————— +===—————— +-==—————— +====————— | 
* | DEV CLOSE | device | proc nr | | | | 
E |======2====5 +--------- +--------- +--------- +--------- +--------- 
* | DEV_READ | device | proc nr | bytes | offset | buf ptr | 
PAs p===—————— +====————— E +-==—————— SRssS=s e | 
* | DEV WRITE | device | proc nr | bytes | offset | buf ptr | 
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11020 
11021 
11022 
11023 
11024 
11025 
11026 
11027 
11028 
11029 
11030 
11031 
11032 
11033 
11034 
11035 
11036 
11037 
11038 
11039 
11040 
11041 
11042 
11043 
11044 
11045 
11046 
11047 
11048 
11049 
11050 
11051 
11052 
11053 
11054 
11055 
11056 
11057 
11058 
11059 
11060 
11061 
11062 
11063 
11064 
11065 
11066 
11067 
11068 
11069 
11070 
11071 
11072 
11073 
11074 
11075 
11076 
11077 
11078 
11079 


------------ +---------+---------+---------+---------+-------- 
* | DEV_GATHER | device proc nr | iov len offset | iov ptr 
A A d===—==——— +--------- ===—————— &===—=———— +====—=—— 
* | DEV SCATTER| device proc nr | iov len offset | iov ptr 
dna ss ass +--------- +--------- +--------- +--------- +-------- 
j DEV_IOCTL | device proc nr |func code buf ptr 
* |------------ +--------- +--------- +--------- +--------- +-------- 
* CANCEL device proc nr r/w 

* =sE==.s===.- +--------- +--------- +--------- +--------- +-------- 
id HARD STOP 


* O arquivo contém um ponto de entrada: 


* driver task: chamada pela entrada de tarefa dependente de dispositivo 
*/ 
tinclude "../drivers.h" 


tinclude <sys/ioc disk.h> 
ginclude "driver.h” 


define BUF EXTRA 0 


/* Reivindica espaço para variáveis. */ 

PRIVATE u8 t buffer[ (unsigned) 2 * DMA BUF SIZE + BUF EXTRA]; 

u8 t *tmp buf; /* o buffer de DMA finalmente */ 

phys bytes tmp phys; /* endereço físico do buffer de DMA */ 


FORWARD | PROTOTYPE( void init buffer, (void) ); 
FORWARD | PROTOTYPE( int do rdwt, (struct driver *dr, message *mp) ); 
FORWARD | PROTOTYPE( int do vrdwt, (struct driver *dr, message *mp) ); 


int device caller; 


[/B==============>==>===>>=>>=>==>=>==>>=>>=>>=>==>=>=>=>>>>=>=>>=>=>>=>>>>=>>=>=>=>=>>>>=>==>==>===> * 
* driver task * 
EEDDS==S==DDDD>=>>=D>=>>=>>=>=>>=>>=>>=>>=>>>=>>=>>=>>>>>=>=>>=>=>>>>>>>>>>=>=>>>=>>>==>==>=>==> * / 

PUBLIC void driver task(dp) 

struct driver *dp; /* Pontos de entrada dependentes de dispositivo. */ 

{ 


/* Programa principal de qualquer tarefa de driver de dispositivo. */ 


int r, proc nr; 
message mess; 


/* Obtém um buffer de DMA. */ 
init bufferO; 


/* Aqui está o laço principal da tarefa de disco. Ele espera por uma mensagem, a 
* executa e envia uma resposta. 
*/ 

while (TRUE) { 


/* Espera por uma requisição para ler ou escrever um bloco de disco. */ 
if(receive(ANY, &mess) != OK) continue; 


device caller = mess.m source; 
proc nr = mess.PROC NR; 


/* Agora realiza o trabalho. */ 
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11080 switch(mess.m type) { 

11081 case DEV OPEN: r = (*dp->dr open)(dp, &mess); break; 

11082 case DEV CLOSE: r = (*dp->dr close) (dp, &mess); break; 

11083 case DEV IOCTL: r = (*dp->dr ioctl) (dp, &mess); break; 

11084 case CANCEL: r = (*dp->dr cancel) (dp, &mess);break; 

11085 case DEV SELECT: r (C*dp->dr select) (dp, &mess); break; 

11086 

11087 case DEV READ: 

11088 case DEV WRITE: r = do rdwt(dp, ê&mess); break; 

11089 case DEV GATHER: 

11090 case DEV SCATTER: r = do vrdwt(dp, &mess); break; 

11091 

11092 case HARD INT: /* interrupção restante ou temporizador expirado. */ 
11093 if(Cdp->dr hw int) { 

11094 (C*dp->dr hw int) (dp, ê&mess); 

11095 } 

11096 continue; 

11097 case SYS_SIG: C*dp->dr_signal)(dp, &mess); 

11098 continue; /* não responde */ 

11099 case SYN ALARM: (C*dp->dr alarm) (dp, ê&mess); 

11100 continue; /* não responde */ 

11101 default: 

11102 if(dp->dr other) 

11103 r = (*dp->dr other) (dp, &mess); 

11104 else 

11105 r = EINVAL; 

11106 break; 

11107 

11108 

11109 /* Limpeza do estado restante. */ 

11110 (C*dp->dr cleanup) O; 

11111 

11112 /* Finalmente, prepara e envia a mensagem de resposta. */ 

11113 if Cr != EDONTREPLY) 1 

11114 mess.m type = TASK REPLY; 

11115 mess.REP PROC NR = proc nr; 

11116 /* O status é o nº de bytes transferidos ou código de erro. */ 
11117 mess.REP STATUS = r; 

11118 send(device caller, &mess); 

11119 fi 

11120 } 

11121 } 

11123 /*==2 
11124 * init buffer * 
11125 a = É 
11126 PRIVATE void init bufferO 

11127 { 

11128 /* Seleciona um buffer que possa ser usado com segurança para transferências de DMA. Ele 
11129 * também pode ser usado para ler tabelas de partição e coisas desse tipo. Seu endereço 
11130 * absoluto é "tmp phys”, o endereço normal é "tmp buf”. 

11131 */ 

11132 

11133 unsigned left; 

11134 


11135 tmp buf = buffer; 

11136 sys umap(SELF, D, (vir bytes)buffer, (phys bytes)sizeof(buffer), &tmp phys); 

11137 

11138 if (Cleft = dma bytes lTeftCtmp phys)) < DMA BUF SIZE) { 

11139 /* A primeira metade do buffer ultrapassa um limite de 64K. Não se pode usar DMA. */ 
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tmp buf += left; 
tmp phys += left; 


PRIVATE int do rdwt(dp, mp) 

struct driver *dp; /* pontos de entrada dependentes de dispositivo */ 
message *mp; /* ponteiro para mensagem de leitura ou escrita */ 
{ 


/* Executa um único pedido de leitura ou escrita. */ 
iovec_t iovecl; 
int r, opcode; 
phys_bytes phys_addr; 


/* Endereço de disco? Endereço e comprimento do buffer de usuário? */ 
if (mp->COUNT < 0) return(EINVAL); 


/* Verifica o buffer de usuário. */ 
sys_umap(mp->PROC_NR, D, (vir_bytes) mp->ADDRESS, mp->COUNT, &phys_addr); 
if (phys_addr == 0) return(EFAULT); 


/* Prepara para E/S. */ 
if ((C*dp->dr prepare) (mp->DEVICE) == NIL DEV) return(ENXIO); 


/* Cria um único vetor de dispersão/reunião de elementos para o buffer. */ 
opcode = mp->m type == DEV READ ? DEV GATHER : DEV SCATTER; 

iovecl.iov addr = (vir bytes) mp->ADDRESS; 

iovecl.iov size = mp->COUNT; 


/* Transfere bytes de/para o dispositivo. */ 
r = (*dp->dr transfer) (mp->PROC NR, opcode, mp->POSITION, &iovecl, 1); 


/* Retorna o número de bytes transferidos ou um código de erro. */ 
return(r == OK ? (mp->COUNT - iovecl.iov size) : r); 


PRIVATE int do vrdwt(dp, mp) 


struct driver *dp; /* pontos de entrada dependentes de dispositivo */ 
message *mp; /* ponteiro para mensagem de leitura ou escrita */ 
{ 


/* Realiza uma leitura ou escrita de dispositivo para/a partir de um vetor de endereços 
* de usuário. Os "endereços de usuário" são supostamente seguros, isto é, o SA 

* transferindo para/de seus próprios buffers; portanto, eles não são verificados. 
*/ 

static iovec t iovec[NR IOREQS]; 

iovec t *iov; 

phys bytes iovec size; 

unsigned nr reg; 

int rs 


nr req = mp->COUNT; /* Comprimento do vetor de E/S */ 


if (mp->m source < 0) 1 
/* Chamada por uma tarefa, não precisa copiar vetor. */ 
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11200 iov = (iovec t *) mp->ADDRESS; 

11201 } else { 

11202 /* Copia o vetor do processo que fez a chamada para o espaço do núcleo. */ 
11203 if (nr req > NR_IOREQS) nr req = NR_IOREQS; 

11204 iovec size = (phys bytes) (nr reg * sizeof(iovec[0])); 

11205 

11206 if (OK != sys datacopy(mp->m source, (vir bytes) mp->ADDRESS, 
11207 SELF, (vir bytes) iovec, iovec size)) 

11208 panic((*dp->dr name) O,"bad I/O vector by", mp->m source); 
11209 iov = iovec; 

11210 } 

11211 


11212 /* Prepara para E/S. */ 
11213 if (C*dp->dr prepare) (mp->DEVICE) == NIL DEV) return(ENXIO) ; 


11215 /* Transfere bytes do/para o dispositivo. */ 
11216 r = (*dp->dr transfer) (mp->PROC NR, mp->m type, mp->POSITION, iov, nr reg); 


11218 /* Copia o vetor de E/S de volta no processo que fez a chamada. */ 

11219 if (mp->m source >= 0) 1 

11220 sys datacopy(SELF, (vir bytes) iovec, 

11221 mp->m source, (vir bytes) mp->ADDRESS, iovec size); 

11222 } 

11223 return(r); 

11224 3 

11226  /f========DDDDDD5D==D==D=D==2==D==5=====2==2==2=====2=================================* 

11227 * no_name * 

11228 EE cnsSSSSESESSSDDS SE ESSES s=nssssas========>==========—>= ===" / 
11229 PUBLIC char *no name() 

11230 { 

11231 /* Usa este nome padrão, se não houver nenhum nome específico para o dispositivo. Isso era 
11232 * feito originalmente por meio da busca do nome da tabela de tarefas deste processo: 
11233 * "return(tasktab[proc number(proc ptr) + NR TASKS] .name);", mas atualmente um 
11234 * "noname" real é retornado. Talvez algum serviço de informação de sistema possa ser 
11235 * consultado para se obter um nome, posteriormente. 

11236 RÁ 

11237 static char name[] = "noname"; 

11238 return name; 

11239 + 

11241 0 /*================>=D=>=DD>>=>=D==>=2=>=D>D==>>=>=2==>=>=>=>>==>=>======>==>========>>========* 
11242 * do nop 

11243  *========2=22222 Y 


11244 PUBLIC int do_nop(dp, mp) 
11245 struct driver *dp; 
11246 message *mp; 


11247 { 

11248 /* Nada ada para fazer. */ 

11249 

11250 switch (mp->m_type) { 

11251 case DEV_OPEN: return (ENODEV) ; 
11252 case DEV_CLOSE: return(0K); 
11253 case DEV IOCTL: return(ENOTTY) ; 
11254 default: return(EIO); 
11255 } 
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11258  /%================D=D=D=DD>=D=D=D=D=>D=2D>D=D>D=>=2=>=>=2=>=>>D==>=>=>===>=====>=====>=====>>========* 
11259 E nop signal 
11260 FEEDS SDS DESS DS DOSES DCE SSSD ESSES ESSES to 
11261 PUBLIC void nop signal(dp, mp) 

11262 struct driver *dp; 

11263 message “mp; 


11264 { 

11265 /* A ação padrão para sinal é ignorar. */ 

11266 + 

11268  /%===================>=>="=>D=>>=2=>D=DD0=D=>=2=D=>=2==D=>=2=======2=>===================* 
11269 $ nop_alarm di 
11270 ¥===2 505 DDD S=DDDSDDSSDDEDDODDDS SD DDDDESDOS DES DDDDoc=DD=*/ 


11271 PUBLIC void nop alarm(dp, mp) 
11272 struct driver *dp; 
11273 message “mp; 


11274 { 

11275 /* Ignora o alarme restante. */ 

11276 3 

11278 

11279 

11280 

11281 PUBLIC struct device *nop prepare(device) 

11282 { 

11283 /* Nada para preparar. */ 

11284 return(NIL DEV); 

11285 3 

11287 /Z===DDDD=D=D=DDD==DD=D=>D>D2>D2>=2D=>D>D>D2>2==2>=D==2=2==2==>>=>="=02==>=>=>==========— * 
11288 $ nop_cleanup i 
11289 * ===> ¥*Ý / 
11290 PUBLIC void nop_cleanupO 

11291 { 

11292 /* Nada para limpar. */ 

11293 + 

11295 

11296 

11297 

11298 

11299 { 

11300 /* Nada a fazer para cancelar. */ 

11301 return(OK); 

11302 + 

11304 

11305 

11306 ? = 

11307 PUBLIC int nop select(struct driver *dr, message *m) 
11308 { 

11309 /* Nada a fazer para selecionar. */ 

11310 return(OK); 

11311 3 

11313 

11314 

11315 


11316 PUBLIC int do diocnt](dp, mp) 
11317 struct driver *dp; 
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11318 
11319 
11320 
11321 
11322 
11323 
11324 
11325 
11326 
11327 
11328 
11329 
11330 
11331 
11332 
11333 
11334 
11335 
11336 
11337 
11338 
11339 
11340 
11341 
11342 
11343 
11344 
11345 
11346 
11347 
11348 
11349 
11350 
11351 


message *mp; /* ponteiro para requisição de ioctl */ 
{ 
/* Executa uma requisição de configuração/obtenção de partição. */ 
struct device *dv; 
struct partition entry; 
int s: 


if (mp->REQUEST != DIOCSETP && mp->REQUEST != DIOCGETP) { 
if(dp->dr other) { 
return dp->dr other(dp, mp); 
} else return(ENOTTY); 
} 


/* Decodifica os parâmetros da mensagem. */ 
if ((dv = (*dp->dr prepare) (mp->DEVICE)) == NIL DEV) return(ENXIO) ; 


if (mp->REQUEST == DIOCSETP) 1 
/* Copia apenas esta entrada da tabela de partição. */ 
if (OK != (s=sys datacopy(mp->PROC NR, (vir bytes) mp->ADDRESS, 
SELF, (vir bytes) &entry, sizeof(entry)))) 
return s; 
dv->dv base = entry.base; 
dv->dv size = entry.size; 
} else { 


/* Retorna uma entrada da tabela de partição e a geometria da unidade de disco. 


entry.base = dv->dv base; 
entry.size = dv->dv size; 
(*dp->dr. geometry) (&entry); 
if (OK != (s=sys datacopy(SELF, (vir bytes) &entry, 
mp->PROC NR, (vir bytes) mp->ADDRESS, sizeof(entry)))) 
return s; 


return(OK); 


AAA ++ 
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11400 
11401 
11402 
11403 
11404 
11405 
11406 
11407 
11408 
11409 
11410 
11411 
11412 
11413 
11414 
11415 
11416 
11417 
11418 
11419 


/* Funções utilitárias de driver de dispositivo IBM. Autor: Kees J. Bot 


7 de dezembro de 1995 


* Ponto de entrada: 
* partição: particiona um disco na(s) tabela(s) de partição nele presente(s). 


*/ 


#include "driver.h" 
#include "drvlib.h" 
#include <unistd.h> 


/* Partição estendida? */ 
#define ext_part(s) (Cs) == 0x05 || (s) == 0x0F) 


FORWARD | PROTOTYPE( void extpartition, (struct driver *dp, int extdev, 
unsigned long extbase) ); 
FORWARD _PROTOTYPE(Ç int get part table, (struct driver *dp, int device, 
unsigned long offset, struct part entry *table)); 
FORWARD | PROTOTYPE( void sort, (struct part entry *table) ); 


#ifndef CD SECTOR SIZE 
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11420 
11421 
11422 
11423 
11424 
11425 
11426 
11427 
11428 
11429 
11430 
11431 
11432 
11433 
11434 
11435 
11436 
11437 
11438 
11439 
11440 
11441 
11442 
11443 
11444 
11445 
11446 
11447 
11448 
11449 
11450 
11451 
11452 
11453 
11454 
11455 
11456 
11457 
11458 
11459 
11460 
11461 
11462 
11463 
11464 
11465 
11466 
11467 
11468 
11469 
11470 
11471 
11472 
11473 
11474 
11475 
11476 
11477 
11478 
11479 


tdefine CD SECTOR SIZE 2048 
#endif 


Jann a a a a a a a 


partition 


PUBLIC void partition(dp, device, style, atapi) 


struct driver *dp; /* pontos de entrada dependentes de dispositivo */ 

int device; /* dispositivo a particionar */ 

int style; /* estilo de particionamento: disquete, primário, sub. */ 
int atapi; /* dispositivo atapi */ 

{ 


/* Esta rotina é chamada na primeira abertura para inicializar as tabelas de partição 
* de um dispositivo. Ela garante que cada partição caia seguramente dentro dos limites 
* do dispositivo. Dependendo do estilo de partição, estamos fazendo 
* partições de disquete, partições primárias ou subpartições. Apenas as partições 
primárias são ordenadas, pois são compartilhadas com outros sistemas 
operacionais que esperam isso. 


* 


*/ 
struct part entry table[NR PARTITIONS], *pe; 
int disk, par; 
struct device *dv; 
unsigned long base, limit, part limit; 


/* Obtém a geometria do dispositivo a particionar */ 
if (Cdv = (*dp->dr prepare) (device)) == NIL DEV 
|| cmp64u(dv->dv size, 0) == 0) return; 
base = div64u(dv->dv base, SECTOR SIZE); 
limit = base + div64u(dv->dv size, SECTOR SIZE); 


/* Lê a tabela de partição do dispositivo. */ 
if(!get part table(dp, device, OL, table)) { 
return; 


} 


/* Calcula o número de dispositivo da primeira partição. */ 
switch (style) { 
case P_FLOPPY: 
device += MINOR_fd0p0; 
break; 
case P_PRIMARY: 
sort(table); /* ordena uma tabela de partição primária */ 
device += 1; 
break; 
case P_SUB: 
disk = device / DEV PER DRIVE; 
par = device % DEV PER DRIVE - 1; 
device = MINOR dOp0s0 + (disk * NR PARTITIONS + par) * NR PARTITIONS; 
} 


/* Encontra um conjunto de dispositivos. */ 
if ((dv = (*dp->dr_prepare)(device)) == NIL DEV) return; 


/* Configura a geometria das partições da tabela de partição. */ 
for (par = 0; par < NR_PARTITIONS; par++, dv++) { 
/* Diminui a partição para caber dentro do dispositivo. */ 
pe = &table[par]; 
part limit = pe->lowsec + pe->size; 
if (part limit < pe->lowsec) part limit = limit; 
if (part limit > limit) part limit = limit; 
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11480 if (pe->lowsec < base) pe->lowsec = base; 

11481 if (part Timit < pe->lTowsec) part limit = pe->lowsec; 

11482 

11483 dv->dv base = mul64u(pe->lTowsec, SECTOR SIZE); 

11484 dv->dv size = mul64u(part limit - pe->lTowsec, SECTOR SIZE); 

11485 

11486 if (style == P PRIMARY) { 

11487 /* Cada partição primária do Minix pode ser subparticionada. */ 
11488 if (pe->sysind == MINIX PART) 

11489 partition(dp, device + par, P SUB, atapi); 

11490 

11491 /* Uma partição estendida tem partições lógicas. */ 

11492 if (ext part(pe->sysind)) 

11493 extpartition(dp, device + par, pe->lowsec); 

11494 

11495 } 

11496 } 

11498 /* === 
11499 x extpartition * 
11500 — f====s=s==D====DDD=D=D=D00=D0DDDDDDDoDocoDocDoDocoDocococococococeconeco=n===*/ 
11501 PRIVATE void extpartition(dp, extdev, extbase) 

11502 struct driver *dp; /* pontos de entrada dependentes de dispositivo */ 
11503 int extdev; /* partição estendida a percorrer */ 


11504 unsigned long extbase; /* deslocamento de setor da partição estendida de base */ 
11505 { 
11506 /* As partições estendidas não podem ser ignoradas, pois as pessoas gostam de mover 


11507 * arquivos para (e de) partições do DOS. Evite ler este código, ele não tem graça. 
11508 */ 

11509 struct part entry table[NR PARTITIONS], *pe; 

11510 int subdev, disk, par; 

11511 struct device *dv; 

11512 unsigned long offset, nextoffset; 

11513 


11514 disk = extdev / DEV PER DRIVE; 
11515 par = extdev % DEV PER DRIVE - 1; 
11516 subdev = MINOR d0p0s0 + (disk * NR PARTITIONS + par) * NR PARTITIONS; 


11518 offset = 0; 
11519 do 1 


11520 if (!get part table(dp, extdev, offset, table)) return; 

11521 sort(table); 

11522 

11523 /* A tabela deve conter uma partição lógica e, opcionalmente, 

11524 * outra partição estendida. (Trata-se de uma lista encadeada.) 
11525 */ 

11526 nextoffset = 0; 

11527 for (par = 0; par < NR PARTITIONS; par++) 1 

11528 pe = &table[par]; 

11529 if (ext part(pe->sysind)) 1 

11530 nextoffset = pe->lowsec; 

11531 } else 

11532 if (pe->sysind != NO PART) { 

11533 if (Cdv = (*dp->dr prepare) (subdev)) == NIL DEV) return; 
11534 

11535 dv->dv base = mul64u(extbase + offset + pe->Towsec, 
11536 SECTOR SIZE); 
11537 dv->dv size = mul64u(pe->size, SECTOR SIZE); 

11538 


11539 /* Falta de dispositivos? */ 
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if (++subdev % NR PARTITIONS == 0) return; 
} 
} 
} while ((offset = nextoffset) != 0); 


PRIVATE int get_part_table(dp, device, offset, table) 
struct driver *dp; 
int device; 


unsigned long offset; /* deslocamento de setor para a tabela */ 
struct part_entry *table; /* quatro entradas */ 
{ 
/* Lê a tabela de partição do dispositivo, retorna true se não houve 
* erros. 
*/ 


iovec t iovecl; 
off t position; 
static unsigned char partbuf[CD SECTOR SIZE]; 


position = offset << SECTOR SHIFT; 
iovecl.iov addr = (vir bytes) partbuf; 
iovecl.iov size = CD SECTOR SIZE; 
if ((*dp->dr prepare) (device) != NIL DEV) 1 
(void) (*dp->dr transfer) (SELF, DEV GATHER, position, &iovecl, 1); 


} 

if Ciovecl.iov_size != 0) { 
return 0; 

} 


if (partbuf[510] != 0x55 || partbuf[511] != OxAA) { 
/* Tabela de partição inválida. */ 


return 0; 
} 
memcpy(table, (partbuf + PART TABLE OFF), NR PARTITIONS * sizeof(table[0])); 
return 1; 
} 
/* === ¥ 
* sor t K 
* === * / 


PRIVATE void sort(table) 

struct part_entry *table; 

{ 

/* Ordena uma tabela de partição. */ 
struct part entry *pe, tmp; 
int n = NR PARTITIONS; 


do 1 
for (pe = table; pe < table + NR PARTITIONS-1; pe++) 1 
if (pe[0].sysind == NO PART 
|| Cpe[0].1owsec > pe[1].1Towsec 
&& pe[1].sysind != NO PART)) { 
tmp = pe[0]; pe[0] = pe[1]; pe[1] = tmp; 
} 
} 
} while (--n > 0); 
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DO o eo DO SO a O O HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O O DO OO OO O RS 
drivers/memory/memory.c 
HHHEHHHHHHHHH + HHHH HHHH HHHH HHHH HHHH HH HHHH OO O O DD H+H O SD DO OO OO O O 


11600 /* Este arquivo contém a parte dependente de dispositivo dos drivers para os 


11601 * arquivos especiais seguintes: 

11602 é /dev/ram - disco de RAM 

11603 e /dev/mem - memória absoluta 

11604 y /dev/kmem - memória virtual do núcleo 

11605 x /dev/null - dispositivo nulo (depósito de dados) 

11606 $ /dev/boot - dispositivo usado pela imagem de inicialização 

11607 $ /dev/zero - gerador de fluxo de byte nulo 

11608 * 

11609 * Alterações: 

11610 Ed 29 de abril de 2005 gerador de byte nulo adicionado (Jorrit N. Herder) 

11611 s 09 de abril de 2005 suporte para dispositivo de inicialização (Jorrit N. Herder) 
11612 x 26 de julho de 2004 driver de RAM em espaço do usuário (Jorrit N. Herder) 

11613 + 20 de abril de 1992 divisão entre dependente/independente de dispositivo (K. J. Bot) 
11614 */ 

11615 


11616 &include "../drivers.h" 

11617 &include "../Tibdriver/driver.h" 
11618 #include <sys/ioc memory .h> 
11619 &include "../../kernel/const.h" 
11620 &include "../../kernel/config.h"” 
11621 &include "../../kernel/type.h" 


11622 

11623 &include "assert.h" 

11624 

11625 &define NR DEVS 6 /* número de dispositivos secundários */ 
11626 

11627 PRIVATE struct device m geom[NR DEVS]; /* base e tamanho de cada dispositivo */ 
11628 PRIVATE int m seg[NR DEVS]; /* índice de segmento de cada dispositivo */ 
11629 PRIVATE int m device; /* dispositivo corrente */ 

11630 PRIVATE struct kinfo kinfo; /* informação do núcleo*/ 

11631 PRIVATE struct machine machine; /* informação da máquina */ 

11632 

11633 extern int errno; /* número de erro para chamadas do PM */ 
11634 

11635 FORWARD | PROTOTYPE( char *m name, (void) Jė 

11636 FORWARD _PROTOTYPE( struct device *m_prepare, (int device) )5 

11637 FORWARD | PROTOTYPE( int m transfer, (int proc nr, int opcode, off t position, 
11638 iovec t *iov, unsigned nr req) ); 


11639 FORWARD PROTOTYPE( int m do open, (struct driver *dp, message *m ptr) ); 
11640 FORWARD | PROTOTYPE( void m init, (void) ); 


11641 FORWARD PROTOTYPE( int m ioctl, (struct driver *dp, message *m ptr) J 
11642 FORWARD _PROTOTYPE( void m_geometry, (struct partition *entry) Jè 
11643 


11644 /* Pontos de entrada para este driver. */ 
11645 PRIVATE struct driver m dtab = { 


11646 m name, /* nome do dispositivo corrente */ 

11647 m do open, /* abre ou monta */ 

11648 do nop, /* nada em um fechamento */ 

11649 m ioctl, /* geometria específica do disco de ram */ 

11650 m prepare, /* prepara para E/S em determinado dispositivo secundário */ 
11651 m transfer, /* realiza a E/S */ 

11652 nop cleanup, /* não precisa limpar */ 

11653 m geometry, /* "geometria" do dispositivo de memória */ 


11654 nop signal, /* sinais do sistema */ 
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11655 
11656 
11657 
11658 
11659 
11660 
11661 
11662 
11663 
11664 
11665 
11666 
11667 
11668 
11669 
11670 
11671 
11672 
11673 
11674 
11675 
11676 
11677 
11678 


11680 
11681 
11682 
11683 
11684 
11685 
11686 
11687 
11688 


11690 
11691 
11692 
11693 
11694 
11695 
11696 
11697 
11698 
11699 
11700 
11701 


11703 
11704 
11705 
11706 
11707 
11708 
11709 
11710 
11711 
11712 
11713 
11714 


nop alarm, 
nop cancel, 
nop select, 
NULL, 
NULL 

3; 


/* Buffer para o alimentador de byte nulo /dev/zero. */ 
tdefine ZERO BUF SIZE 1024 
PRIVATE char dev zero[ZERO BUF SIZE]; 


gdefine click to round k(n) N 
(Cunsigned) ((CCunsigned Tong) (n) << CLICK SHIFT) + 512) / 1024)) 


[/B==============>=====>==>>=>==>=>=>>=>>=>=>=>=>=>=>=>=>>>=>>=>=>=>>>>>>=>=>>=>=>=>>=>>=>==>=>===> * 
* main fe 
* E ===================== * / 

PUBLIC int main(void) 

{ 


/* Programa principal. Inicializa o driver de memória e inicia o laço principal. */ 
minitO; 
driver task(&m dtab); 


return(OK); 
} 
Ji >>. * 
x m name + 
X Se= * / 
PRIVATE char *m_name O 
{ 
/* Retorna um nome para o dispositivo corrente. */ 
static char name[] = "memory"; 
return name; 
} 
EEE A E E 
$ m_prepare # 
eE E E a) 


PRIVATE struct device *m_prepare(device) 

int device; 

{ 

/* Prepara E/S em dispositivo: testa validade do nro de disp. secundário */ 
if (device < O || device >= NR DEVS) return(NIL DEV); 
m device = device; 


return(&m geom[device]); 


PRIVATE int m transfer(proc nr, opcode, position, iov, nr reg) 
int proc nr; * processo que está fazendo a requisição */ 
int opcode; * DEV GATHER ou DEV SCATTER */ 
off t position; * deslocamento no dispositivo a ler ou escrever */ 
iovec t *iov; * ponteiro para vetor de requisição de leit./esc. */ 
unsigned nr reg; * comprimento do vetor de requisição */ 
{ 
/* Lê ou escreve um dos dispositivos secundários do driver. */ 
phys bytes mem phys; 


ER 
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11715 
11716 
11717 
11718 
11719 
11720 
11721 
11722 
11723 
11724 
11725 
11726 
11727 
11728 
11729 
11730 
11731 
11732 
11733 
11734 
11735 
11736 
11737 
11738 
11739 
11740 
11741 
11742 
11743 
11744 
11745 
11746 
11747 
11748 
11749 
11750 
11751 
11752 
11753 
11754 
11755 
11756 
11757 
11758 
11759 
11760 
11761 
11762 
11763 
11764 
11765 
11766 
11767 
11768 
11769 
11770 
11771 
11772 
11773 
11774 


int seg; 

unsigned count, left, chunk; 
vir bytes user vir; 

struct device *dv; 

unsigned long dv size; 


ints: 


/* Obtém número do dispositivo secundário e verifica /dev/null. */ 
dv = &m geom[m device]; 
dv size = cv64ul(dv->dv size); 


while 


(nr req > 0) 1 


/* Quanto deve transferir e para/de onde. * 


count = iov->iov size; 
user vir = iov->iov addr; 


switch (m device) 1 


/* Nenhuma cópia; ignora o pedido. */ 
case NULL DEV: 
if (opcode == DEV GATHER) return(OK); 
break; 


/* Cópia virtual. Para disco de RAM, mem. do núcleo e disp. de inicialização. 


case RAM DEV: 
case KMEM DEV: 
case BOOT DEV: 
if (position >= dv size) return(OK); 


/* sempre ao EOF */ 


/* verifica EOF */ 


if (position + count > dv size) count = dv size - position; 


seg = m seg[m device]; 


if (opcode == DEV GATHER) { 


/* copia dados reais */ 


sys vircopy(SELF,seg,position, proc nr,D,user vir, count); 


} else { 


sys_vircopy(proc_nr,D,user_vir, SELF,seg,position, count); 


} 


break; 


/* Cópia física. Usada apenas para acessar a memória inteira. */ 


case MEM_DEV: 
if (position >= dv size) return(0K); 


/* check for EOF */ 


if (position + count > dv size) count = dv size - position; 


mem phys = cv64ul(dv->dv base) + position; 


if (opcode == DEV GATHER) { 


sys. physcopy (NONE, PHYS SEG, mem phys, 


proc nr, D, user vir, count 
} else { 
sys physcopy(proc nr, D, user vir, 


J; 


/* copia dados */ 


NONE, PHYS SEG, mem phys, count); 


} 


break; 


/* Gerador de fluxo de byte nulo. */ 
case ZERO_DEV: 
if (opcode == DEV_GATHER) { 
left = count; 
while (left > 0) { 


chunk = (left > ZERO_BUF_SIZE) ? ZERO_BUF_SIZE : left; 


*/ 
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11775 
11776 
11777 
11778 
11779 
11780 
11781 
11782 
11783 
11784 
11785 
11786 
11787 
11788 
11789 
11790 
11791 
11792 
11793 
11794 
11795 
11796 


11798 
11799 
11800 
11801 
11802 
11803 
11804 
11805 
11806 
11807 
11808 
11809 
11810 
11811 
11812 


11814 
11815 
11816 
11817 
11818 
11819 
11820 
11821 
11822 
11823 
11824 
11825 
11826 
11827 
11828 
11829 
11830 
11831 
11832 
11833 
11834 


if (OK != (s=sys vircopy(SELF, D, (vir bytes) dev zero, 
proc nr, D, user vir, chunk))) 
report ("MEM","sys vircopy failed", s); 
left -= chunk; 
user_vir += chunk; 


} 
} 
break; 
/* Dispositivo secundário desconhecido (inválido). */ 
default: 
return(EINVAL); 
} 


/* Registra o número de bytes transferidos. */ 
position += count; 

iov->iov addr += count; 

if (Ciov->iov size -= count) == 0) { iov++; nr req--; 5 


return(OK); 


PRIVATE int m do open(dp, m ptr) 
struct driver *dp; 
message “*m ptr; 


{ 


/* Verifica nr. do dispositivo na abertura. (Isso é usado para dar privilégios de E/S para 


um processo que abre /dev/mem ou /dev/kmem. Isso pode ser necessário no caso de E/S 


* mapeada em memória. Com chamadas de sistema para E/S, isso não é mais necessário.) 


*/ 


if (m_prepare(m_ptr->DEVICE) == NIL DEV) return(ENXIO); 


return(0K); 


PRIVATE void m initO 
{ 


/* Inicializa esta tarefa. Todos os dispositivos secundários são inicializados um a um. 


Tnt i,s; 


if (OK != (s=sys_getkinfo(&kinfo))) { 
panic("MEM","Couldn't get kernel information. ",s); 


} 


/* Instala segmento remoto para memória /dev/kmem. */ 
m_geom[KMEM_DEV] .dv_base = cvul64(kinfo.kmem_base); 
m_geom[KMEM_DEV] .dv_size = cvul64(kinfo.kmem_size); 
if (OK != (s=sys segctl(&m seg[KMEM DEV], (U16 t *) &s, (vir bytes *) &s, 
kinfo.kmem base, kinfo.kmem size))) 1 
panic("MEM","Couldn't install remote segment.",s); 


} 


/* Instala segmento remoto para memória /dev/boot, se estiver ativado. */ 


*/ 
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11835 m geom[BOOT DEV] .dv base = cvul64(kinfo.bootdev base); 
11836 m geom[BOOT DEV] .dv size = cvul64(kinfo.bootdev size); 
11837 if (kinfo.bootdev base > 0) { 


11838 if (OK != (s=sys segctl(&m seg[BOOT DEV], (ul6 t *) &s, (vir bytes *) &s, 
11839 kinfo.bootdev base, kinfo.bootdev size))) 1 

11840 panic("MEM","Couldn't install remote segment.",s); 

11841 

11842 } 

11843 

11844 /* Inicializa /dev/zero. Apenas escreve zeros no buffer. */ 

11845 for (i=0; i<ZERO BUF SIZE; i++) { 

11846 dev zero[i] = "NO"; 

11847 } 

11848 

11849 /* Configura intervalos de memória para /dev/mem. */ 

11850 if (OK != (s=sys getmachine(&machine))) { 

11851 panic("MEM","Couldn't get machine information.",s); 

11852 } 

11853 if (! machine.protected) { 

11854 m_geom[MEM_DEV] .dv_size = cvul64(0x100000); /* 1M para sistemas 8086 */ 
11855 } else { 

11856 m_geom[MEM_DEV] .dv_size = cvul64(0xFFFFFFFF); /* 4G-1 para sistemas 386 */ 
11857 } 

11858 3 

11860 — /f==================================>======================================== * 
11861 $ m ioct] # 
11862 oD=D==========================>===================>======================== * / 
11863 PRIVATE int m ioctl(dp, m ptr) 

11864 struct driver *dp; /* ponteiro para estrutura de driver */ 
11865 message “m ptr; /* ponteiro para mensagem de controle */ 
11866 { 


11867 /* Controles de E/S para o driver de memória. Atualmente, existe apenas um controle de E/S: 
11868 * — MIOCRAMSIZE: para configurar o tamanho do disco de RAM. 


11869  */ 

11870 struct device *dv; 

11871 if ((dv = m prepare(m ptr->DEVICE)) == NIL DEV) return(ENXIO); 
11872 

11873 switch (m ptr->REQUEST) { 

11874 case MIOCRAMSIZE: { 

11875 /* O FS quer criar um novo disco de RAM com o tamanho dado. */ 
11876 phys bytes ramdev size; 

11877 phys bytes ramdev base; 

11878 int s; 

11879 

11880 if Cm ptr->PROC NR != FS PROC NR) 1 

11881 report("MEM", “warning, MIOCRAMSIZE called by", m ptr->PROC NR); 
11882 return(EPERM); 

11883 } 

11884 

11885 /* Tenta alocar uma parte da memória para o disco de RAM. */ 
11886 ramdev_size = m_ptr->POSITION; 

11887 if (allocmem(ramdev_size, &ramdev_base) < 0) { 

11888 report("MEM", "warning, allocmem failed", errno); 

11889 return(ENOMEM) ; 

11890 } 

11891 dv->dv_base = cvul64(ramdev_base); 

11892 dv->dv_size = cvul64(ramdev size); 

11893 


11894 if (OK != (s=sys segctl(&m seg[RAM DEV], (ul6 t *) &s, (vir bytes *) &s, 
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} 


} 


ramdev_base, ramdev_size))) { 
panic("MEM","Couldn't install remote segment.",s); 


break; 


} 


default: 
return(do_diocnt](&m_dtab, m_ptr)); 


return(0K); 


PRIVATE void m geometry(entry) 
struct partition *entry; 


{ 


/* Os dispositivos de memória não têm geometria, mas o mundo externo insiste. */ 
entry->cylinders = div64u(m_geom[m_device].dv_size, SECTOR_SIZE) / (64 * 32); 
entry->heads = 64; 

entry->sectors = 32; 
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drivers/at_wini/at_wini.h 


HEHEHEHEHE HHHH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


12000 
12001 
12002 
12003 
12004 
12005 
12006 
12007 


#in 


" 


clude 


../drivers.h" 


#include "../libdriver/driver.h" 
#include "../libdriver/drvlib.h" 


_PROTOTYPE(Çint main, (void)); 


#define VERBOSE 0 /* exibe msg de identificação na inicialização */ 
tdefine ENABLE ATAPI 0 /* adiciona suporte para cd-rom ATAPI no driver */ 


PARAR ++ 


drivers/at wini/at wini.c 


PARAR ++ 


12100 
12101 
12102 
12103 
12104 
12105 
12106 
12107 
12108 
12109 
12110 
12111 
12112 
12113 
12114 


/* Este arquivo contém a parte dependente de dispositivo de um driver para a 
* controladora de winchester do IBM-AT. Escrito por Adri Koppes. 


O arquivo contém um ponto de entrada: 


at winchester task: entrada principal quando o sistema é criado 
Alterações: 
19 de agosto de 2005 suporte para pci ata, suporta SATA (Ben Gras) 


18 de 
20 de 
23 de 
14 de 
13 de 


novembro de 2004 driver de disco AT em espaço do usuário (Jorrit N. Herder) 
agosto de 2004 cães de guarda trocado por alarmes síncronos (Jorrit N. Herder) 
março de 2000 suporte para CDROM ATAPI adicionado (Michael Temari) 

maio de 2000 d-d/i reescrito (Kees J. Bot) 

abril de 1992 divisão entre dependente/independente de dispositivo (Kees J. Bot) 
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12115 

12116 &include "at wini.h" 

12117 &include "../Tibpci/pci.h" 

12118 

12119 &include <minix/sysutil.h> 

12120 &include <minix/keymap.h> 

12121 &include <sys/ioc disk.h> 

12122 

12123 &define ATAPI DEBUG 0 /* Para depurar código ATAPI. */ 
12124 

12125 /* Portas de E/S usadas pelas controladoras de disco winchester. */ 
12126 

12127 /* Registradores de leitura e escrita */ 

12128 #define REG CMD BASEO  OxlFO /* registrador de base de comando da controladora O */ 


12129 ádefine REG CMD BASEI 0x170 /* registrador de base de comando da controladora 1 */ 

12130 ádefine REG CTL BASEO  0x3F6  /* registrador de base de controle da controladora 0 */ 

12131 &define REG CTL BASE1 0x376  /* registrador de base de controle da controladora 1 */ 

12132 

12133 &define REG DATA 0 /* registrador de dados (deslocamento a partir do reg. de 
base) */ 

12134 &define REG PRECOMP 1 /* início da compensação prévia de escrita */ 

12135 &define REG COUNT 2 /* setores a transferir */ 

12136 define REG SECTOR 3 /* número do setor */ 

12137 &define REG CYL LO 4 /* byte inferior do número do cilindro */ 

12138 &define REG CYL HI 5 /* byte superior do número do cilindro */ 

12139 &define REG LDH 6 /* lba, unidade e cabeçote */ 

12140 &define LDH DEFAULT OxAO /* ECC ativo, 512 bytes por setor */ 

12141 &define LDH LBA 0x40 /* Usa endereçamento LBA */ 

12142 define ldh init(drive) CLDH DEFAULT | ((drive) << 4)) 

12143 

12144 /* Registradores de leitura e escrita */ 

12145 &define REG STATUS 7 /* status */ 

12146 &define STATUS BSY 0x80 /* controladora ocupada */ 

12147 #define STATUS RDY 0x40 /* unidade de disco pronta */ 

12148 #define STATUS WF 0x20 /* erro de escrita */ 

12149 &define STATUS SC 0x10 /* busca completa (obsoleto) */ 

12150 &define STATUS DRQ 0x08 /* pedido de transferência de dados */ 

12151 &define STATUS CRD 0x04 /* dados corrigidos */ 

12152 &define STATUS IDX 0x02 /* pulso de índice */ 

12153 &define STATUS ERR 0x01 /* erro */ 

12154 #define STATUS ADMBSY 0x100 /* administrativamente ocupado (software) */ 

12155 &define REG ERROR 1 /* código de erro */ 

12156 #define ERROR BB 0x80 /* bloco danificado */ 

12157 &define ERROR ECC 0x40 /* bytes ecc danificados */ 

12158 &define ERROR ID 0x10 /* id não encontrada */ 

12159 &define ERROR AC 0x04 /* comando cancelado */ 

12160 &define ERROR TK 0x02 /* rastreia erro zero */ 

12161 &define ERROR DM 0x01 /* nenhuma marca de endereço de dados */ 

12162 

12163 /* Registradores apenas de escrita */ 

12164 define REG COMMAND 7 /* comando */ 

12165 &define  CMD IDLE 0x00 /* para w command: unidade de disco ociosa */ 

12166  &define  CMD RECALIBRATE 0x10 /* recalibra unidade de disco */ 

12167 &define  CMD READ 0x20 /* Tê dados */ 

12168 define CMD READ EXT 0x24 /* 1ê dados (endereçados com LBA48) */ 

12169 &define CMD WRITE 0x30 /* grava dados */ 

12170 &define  CMD WRITE EXT 0x34 /* grava dados (endereçados com LBA48) */ 

12171 &define  CMD READVERIFY 0x40 /* verificação da leitura */ 

12172 &define  CMD FORMAT 0x50 /* formata trilha */ 

12173 &define  CMD SEEK 0x70 /* busca cilindro */ 

12174 &define  CMD DIAG 0x90 /* executa diagnóstico de dispositivo */ 
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12175 &define CMD SPECIFY 0x91 /* especifica parâmetros */ 

12176 &define ATA IDENTIFY O0xEC /* identifica unidade de disco */ 

12177 /* &define REG CTL 0x206 */ /* registrador de controle */ 

12178 &define REG CTL 0 /* registrador de controle */ 

12179 &define  CTL NORETRY 0x80 /* desativa nova tentativa de acesso */ 
12180 &define CTL NOECC 0x40 /* desativa nova tentativa de ecc */ 
12181 &define CTL EIGHTHEADS 0x08 /* mais de oito cabeçotes */ 

12182 &define CTL RESET 0x04 /* reconfigura a controladora */ 

12183 gdefine  CTL INTDISABLE 0x02 /* desativa interrupções */ 

12184 

12185 &define REG STATUS 7 /* status */ 

12186  &define STATUS BSY 0x80 /* controladora ocupada */ 

12187 #define STATUS_DRDY 0x40 * unidade de disco pronta */ 

12188 #define STATUS_DMADF 0x20 /* erro de dma pronto/ unidade de disco */ 
12189 #define STATUS_SRVCDSC 0x10 /* serviço ou dsc */ 

12190 #define STATUS_DRQ 0x08 /* pedido de transferência de dados */ 
12191 #define STATUS_CORR 0x04 /* ocorreu erro que pode ser corrigido */ 
12192 #define STATUS_CHECK 0x01 /* verifica erro */ 

12193 

12194 /* Linhas de pedido de interrupção. */ 

12195 #define NO_IRQ (0) /* nenhum IRQ configurado ainda */ 

12196 

12197 #define ATAPI_PACKETSIZE 12 

12198 #define SENSE_PACKETSIZE 18 

12199 


12200 /* Bloco de comandos comum */ 
12201 struct command { 


12202 u8_t precomp; /* REG PRECOMP, etc. */ 
12203 u8 t count; 
12204 u8 t sector; 


12205 u8 t cyl To; 

12206 u8 t cyl hi; 

12207 u8 t Idh; 

12208 u8 t command; 

12209 3; 

12210 

12211 /* Códigos de erro */ 

12212 &define ERR (-D /* erro geral */ 

12213 #define ERR BAD SECTOR (-2) /* bloco marcado como defeituoso detectado */ 
12214 

12215 /* Algumas controladoras não interrompem, o relógio nos despertará. */ 


12216 define WAKEUP (32*HZ) /* unidade de disco pode estar fora por 31s no max */ 
12217 

12218 /* Diversos. */ 

12219 &define MAX DRIVES 8 

12220 define COMPAT DRIVES 4 

12221 &define MAX SECS 256 /* qtde. de setores max. transferidos pela controladora */ 
12222 &define MAX ERRORS 4 /* frequência para tentar rd/wt antes de sair */ 
12223 &define NR MINORS (MAX DRIVES * DEV PER DRIVE) 

12224 &define SUB PER DRIVE (NR PARTITIONS * NR PARTITIONS) 

12225 &define NR SUBDEVS (MAX DRIVES * SUB PER DRIVE) 

12226 &define DELAY USECS 1000 /* tempo limite da controladora em microssegundos */ 
12227 &define DELAY TICKS 1 /* tempo limite da controladora em tiques */ 

12228 &define DEF TIMEOUT TICKS 300 /* tempo limite da controladora em tiques */ 


12229 gdefine RECOVERY USECS 500000 /* tempo de recuperação da controladora em microssegundos */ 
12230 #define RECOVERY TICKS 30 /* tempo de recuperação da controladora em tiques */ 
12231 #define INITIALIZED 0x01 /* a unidade de disco está inicializada */ 

12232 #define DEAF 0x02 /* a controladora deve ser reconfigurada */ 

12233 #define SMART 0x04 /* a unidade de disco suporta comandos ATA */ 

12234 #define ATAPI 0 /* não se preocupa com ATAPI; otimiza */ 
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12235 &define IDENTIFIED 0x10 /* w identify realizado com êxito */ 
12236 define IGNORING 0x20 /* w identify falhou uma vez */ 
12237 


12238 /* Tempos limites e max de novas tentativas. */ 

12239 int timeout ticks = DEF TIMEOUT TICKS, max errors = MAX ERRORS; 
12240 int wakeup ticks = WAKEUP; 

12241 Tong w standard timeouts = 0, w pci debug = 0, w instance = 0, 
12242 w lba48 = 0, atapi debug = 0; 


12243 

12244 int w testing =0,w silent = 0; 

12245 

12246 int w next drive = 0; 

12247 

12248 /* Variáveis. */ 

12249 

12250 /* wini é indexado primeiro pela controladora e, em seguida, a unidade de disco (0-3). 
12251 * a controladora O é sempre a controladora IDE de 'compatibilidade”, nas 

12252 * posições fixas, esteja presente ou não. 

12253 */ 

12254 PRIVATE struct wini { /* estrutura de unidade de disco, uma entrada por unidade */ 
12255 unsigned state; /* estado: sem contato, inicializada, morta */ 

12256 unsigned w status; /* registrador de status de dispositivo */ 

12257 unsigned base cmd; /* registrador de base de comando */ 

12258 unsigned base ctl; /* registrador de base de controle */ 

12259 unsigned irq; /* linha de pedido de interrupção */ 

12260 unsigned irq mask; J= Lee Iraq y 

12261 unsigned irq need ack; /* irq precisa ser reconhecida */ 

12262 int irq hook id; /* id do gancho de irq no núcleo */ 

12263 int 1ba48; /* suporta 1ba48 */ 

12264 unsigned lcylinders; /* número lógico de cilindros (BIOS) */ 

12265 unsigned Theads; /* número lógico de cabeçotes */ 

12266 unsigned Tsectors; /* número lógico de setores por trilha */ 

12267 unsigned pcylinders; /* número físico de cilindros (transformados) */ 
12268 unsigned pheads; /* número físico de cabeçotes */ 

12269 unsigned psectors; /* número físico de setores por trilha */ 

12270 unsigned ldhpref; /* quatro bytes superiores do registrador LDH (cabeçote) */ 
12271 unsigned precomp; /* cilindro de compensação prévia de gravação / 4 */ 
12272 unsigned max count; /* pedido max para essa unidade de disco */ 

12273 unsigned open ct; /* contagem de em uso */ 

12274 struct device part[DEV PER DRIVE]; /* discos e partições */ 

12275 struct device subpart [SUB PER DRIVE]; /* subpartições */ 

12276 } wini[MAX DRIVES], *w wn; 

12277 


12278 PRIVATE int w device = -1; 
12279 PRIVATE int w controller = -1; 
12280 PRIVATE int w major = -1; 
12281 PRIVATE char w id string[40]; 
12282 
12283 PRIVATE int win tasknr; /* meu número de tarefa */ 

12284 PRIVATE int w command; /* comando corrente em execução */ 
12285 PRIVATE u8 t w byteval; /* usado por SYS IRQCTL */ 

12286 PRIVATE int w drive; /* unidade de disco selecionada */ 
12287 PRIVATE int w controller; /* controladora selecionada */ 
12288 PRIVATE struct device *w dv; /* base e tamanho do dispositivo */ 


12289 

12290 FORWARD | PROTOTYPE( void init params, (void) J; 

12291 FORWARD | PROTOTYPE( void init_drive, (struct wini *, int, int, int, int, int, int)); 
12292 FORWARD _PROTOTYPE( void init_params_pci, (int) >; 


12293 FORWARD PROTOTYPE( int w do open, (struct driver *dp, message *m ptr) ); 
12294 FORWARD PROTOTYPE( struct device *w prepare, (int dev) j 
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12295 
12296 
12297 
12298 
12299 
12300 
12301 
12302 
12303 
12304 
12305 
12306 
12307 
12308 
12309 
12310 
12311 
12312 
12313 
12314 
12315 
12316 
12317 
12318 
12319 
12320 
12321 
12322 
12323 
12324 
12325 
12326 
12327 
12328 
12329 
12330 
12331 
12332 
12333 
12334 
12335 
12336 
12337 
12338 
12339 
12340 
12341 
12342 


12344 
12345 
12346 
12347 
12348 
12349 
12350 
12351 
12352 
12353 
12354 


FORWARD | PROTOTYPE( int w identify, (void) DD; 
FORWARD | PROTOTYPE( char *w name, (void) J 
FORWARD _PROTOTYPE(Ç int w specify, (void) Je 
FORWARD _PROTOTYPE(Ç int w io test, (void) Jj 
FORWARD _PROTOTYPE(Ç int w transfer, (int proc nr, int opcode, off t position, 
iovec t *iov, unsigned nr reg) ); 
FORWARD  PROTOTYPE( int com out, (struct command *cmd) ; 
FORWARD _PROTOTYPE( void w need reset, (void) Jė 
FORWARD _PROTOTYPE(Ç void ack_irqs, (unsigned int) J; 
FORWARD | PROTOTYPE( int w do close, (struct driver *dp, message *m_ptr) ); 
FORWARD | PROTOTYPE( int w other, (struct driver *dp, message *m ptr) J; 
FORWARD _PROTOTYPE(Ç int w_hw_int, (struct driver *dp, message *m_ptr) Ji 
FORWARD | PROTOTYPE( int com simple, (struct command *cmd) Js 
FORWARD _PROTOTYPE( void w_timeout, (void) Ji 
FORWARD _PROTOTYPE(Ç int w reset, (void) J3 
FORWARD _PROTOTYPE( void w intr wait, (void) jè 
FORWARD _PROTOTYPE( int at_intr_wait, (void) J; 
FORWARD _PROTOTYPE(Ç int w waitfor, (int mask, int value) je 
FORWARD | PROTOTYPE( void w geometry, (struct partition *entry) J 


/* Pontos de entrada para este driver. */ 
PRIVATE struct driver w_dtab = { 


w_name, /* nome do dispositivo corrente */ 
w do open, /* requisição de abertura ou montagem, inicializa dispositivo */ 
w do close, /* libera dispositivo */ 
do diocnt1, /* obtém ou configura geometria de uma partição */ 
w prepare, /* prepara para E/S em um dispositivo secundário dado */ 
w transfer, /* faz a E/S */ 
nop cleanup, /* nada para limpar */ 
w geometry, /* informa a geometria do disco */ 
nop signal, /* nenhuma limpeza necessária no desligamento */ 
nop alarm, /* ignora alarmes restantes */ 
nop cancel, /* ignora CANCELs */ 
nop select, /* ignora seleções */ 
w other, /* comandos não reconhecidos e ioctls */ 
w hw int /* interrupções de hardware restantes */ 
Fs 
/* === ¥ 
i at_winchester_task ta 
ODDS ====DD=D>=>>>>=>>=>>>=>=>=>=>=>>=>>>>=>=>>=>>=>>>>>>=>>=>>=>>>>>>>>=>>>>=>>=>>>>>===>===> * / 
PUBLIC int mainQO 
{ 


/* Configura parâmetros de disco especiais e depois chama o laços principal genérico. */ 
init_params(); 
driver task(&w dtab); 
return(OK) ; 


PRIVATE void init params (O 
{ 


/* Esta rotina é chamada na partida para inicializar os parâmetros da unidade de disco. */ 


ul6 t parv[2]; 

unsigned int vector, size; 
int drive, nr drives; 
struct wini *wn; 
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12355 
12356 
12357 
12358 
12359 
12360 
12361 
12362 
12363 
12364 
12365 
12366 
12367 
12368 
12369 
12370 
12371 
12372 
12373 
12374 
12375 
12376 
12377 
12378 
12379 
12380 
12381 
12382 
12383 
12384 
12385 
12386 
12387 
12388 
12389 
12390 
12391 
12392 
12393 
12394 
12395 
12396 
12397 
12398 
12399 
12400 
12401 
12402 
12403 
12404 
12405 
12406 
12407 
12408 
12409 
12410 
12411 


12413 
12414 


u8 t params [16]; 
int s? 


/* Variáveis de inicialização. */ 


env parse("ata std timeout", "d", O, &w standard timeouts, O, 1); 
env parse("ata pci debug", "d", O, &w pci debug, O, 1); 
env parse("ata instance”, "d", O, &w instance, 0, 8); 


env parse("ata lba48", "d", O, &w 1ba48, 0, 1); 
env parse("atapi debug", "d", O, &atapi debug, 0, 1); 


if (w instance == 0) { 
/* Obtém o número de unidades de disco a partir da área de dados da BIOS */ 
if ((s=sys vircopy(SELF, BIOS SEG, NR HD DRIVES ADDR, 
SELF, D, (vir bytes) params, NR HD DRIVES SIZE)) != OK) 
panic(w name), "“Couldn't read BIOS", s); 
if ((nr drives = params[0]) > 2) nr drives = 2; 


for (drive = 0, wn = wini; drive < COMPAT DRIVES; drive++, wn++) 1 
if (drive < nr drives) { 

/* Copia o vetor de parâmetros da BIOS */ 

vector = (drive == 0) ? BIOS HDO PARAMS ADDR:BIOS HD1 PARAMS ADDR; 
size = (drive == 0) ? BIOS HDO PARAMS SIZE:BIOS HD1 PARAMS SIZE; 
if ((s=sys vircopy(SELF, BIOS SEG, vector, 

SELF, D, (vir bytes) parv, size)) != OK) 
panic(w name(), "Couldn’t read BIOS", s); 


/* Calcula o endereço dos parâmetros e os copia */ 
if ((s=sys vircopy( 
SELF, BIOS SEG, hclick to physb(parv[1]) + parv[0], 
SELF, D, (phys bytes) params, 16L))!=0K) 
panic(w name(),"Couldn't copy parameters", s); 


/* Copia os parâmetros nas estruturas da unidade de disco */ 
wn->1Tcylinders = bp cylinders(params); 

wn->lheads = bp heads(params); 

wn->Tsectors = bp sectors(params); 

wn->precomp = bp precomp(params) >> 2; 


} 


/* Preenche os parâmetros que não são da BIOS. */ 

init drive(wn, 
drive < 2 ? REG CMD BASEO : REG CMD BASE1, 
drive < 2 ? REG CTL BASEO : REG CTL BASE1, 
NO IRQ, O, O, drive); 

w next drive++; 


} 


/* Procura controladoras no barramento PCI. Não pula na primeira instância, 
* pula um e depois 2 para cada instância. 


*/ 
if (w instance == 0) 
init params pci(0); 
else 


init params pci(w instance*2-1); 
} 


#define ATA_IF_NOTCOMPAT1 (1L << 0) 
#define ATA_IF_NOTCOMPAT2 (1L << 2) 
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12415 
12416 
12417 
12418 
12419 
12420 
12421 
12422 
12423 
12424 
12425 
12426 
12427 
12428 
12429 
12430 
12431 
12432 


12434 
12435 
12436 
12437 
12438 
12439 
12440 
12441 
12442 
12443 
12444 
12445 
12446 
12447 
12448 
12449 
12450 
12451 
12452 
12453 
12454 
12455 
12456 
12457 
12458 
12459 
12460 
12461 
12462 
12463 
12464 
12465 
12466 
12467 
12468 
12469 
12470 
12471 
12472 
12473 
12474 


PRIVATE void init drive(struct wini *w int base cmd int base ctl int irq int ack ... 


{ 


w->state = 0; 

w->w_status = 0; 

w->base_cmd = base_cmd; 
w->base_ctl = base ctl; 
w->irq = irq; 

w->irq mask = 1 << irq; 
w->irq need ack = ack; 

w->irq hook id = hook; 
w->ldhpref = ldh init(drive); 


w->max count = MAX SECS << SECTOR SHIFT; 
w->1ba48 = 0; 


init params p 


PRIVATE void init params pcilint skip) 


{ 


int r, devind, drive; 
ul6 t vid, did; 
pol initO; 
for(drive = w next drive; drive < MAX DRIVES; drive++) 
wini [drive] .state = IGNORING; 
for(r = pci first dev(&devind, &vid, &did); 
r!=08&w next drive<MAX DRIVES; r=pci next dev(&devind,&vid, &did)) { 
int interface, irq, irq hook; 
/* A classe de base deve ser 01h (armazenamento de massa), a subclasse deve 
* ser 01h (ATA). 
*) 
if (pci_attr_r8(devind, PCI_BCR) != 0x01 || 
pci_attr_r8(devind, PCI_SCR) != 0x01) { 
continue; 
} 
/* Encontrou uma controladora. 
* O registrador de interface de programação nos informa mais. 
*/ 
interface = pci_attr_r8(devind, PCI_PIFR); 
irq = pci_attr_r8(devind, PCI_ILR); 


/* Alguma unidade de disco não compatível? */ 
if (interface & CATA IF NOTCOMPATI | ATA IF NOTCOMPAT2)) { 
int s; 
irq hook = irq; 
if (skip > 0) { 
if(w pci debug)printf("atapci skipping contr. (remain %DNn",skip); 
skip--; 
continue; 
} 
if ((s=sys_irqsetpolicy(irq, O, &irq_hook)) != OK) { 
printf("atapci: couldn't set IRQ policy %d\n", irq); 
continue; 
} 
if ((s=sys irgenable(&irq hook)) != OK) { 
printfC“atapci: couldn't enable IRQ line %d\n", irq); 
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12475 
12476 
12477 
12478 
12479 
12480 
12481 
12482 
12483 
12484 
12485 
12486 
12487 
12488 
12489 
12490 
12491 
12492 
12493 
12494 
12495 
12496 
12497 
12498 
12499 
12500 
12501 
12502 
12503 
12504 
12505 
12506 
12507 
12508 
12509 
12510 
12511 
12512 
12513 
12514 
12515 
12516 


12518 
12519 
12520 
12521 
12522 
12523 
12524 
12525 
12526 
12527 
12528 
12529 
12530 
12531 
12532 
12533 
12534 


continue; 
} 
} else { 

/* Se não.. esta não é a controladora ata-pci que estávamos 

* procurando. 

* 

if (w pci debug) printf("atapci skipping compatability controller\n"); 
continue; 


} 


/* Canal primário não está no modo de compatibilidade? */ 
if (interface & ATA IF NOTCOMPATI) { 
u32 t base cmd, base ctl; 
base cmd = pci attr r32(devind, PCI BAR) & Oxffffffeo; 
base ctl = pci attr r32(devind, PCI BAR 2) & Oxffffffeo0; 
if (base cmd != REG CMD BASEO && base cmd != REG CMD BASE1) { 
init drive(&wini [w next drive], 
base cmd, base ctl, irq, 1, irq hook, 0); 
init drive(&wini [w next drive+1], 
base cmd, base ctl, irq, 1, irq hook, 1); 
if (w pci debug) 
printfC“atapci %d: 0x%x 0x%x irq %din",devind,base cmd,base ctl,irq) 
} else printf("atapci: ignored drives on pri, base: %xAn",base cmd); 


} 


/* Canal secundário não está no modo de compatibilidade? */ 
if (interface & ATA_IF_NOTCOMPAT2) { 
u32 t base cmd, base ctl; 
base cmd = pci attr r32(devind, PCI BAR 3) & Oxffffffeo; 
base ctl = pci attr r32(devind, PCI BAR 4) & Oxffffffeo; 
if (base cmd != REG CMD BASEO && base cmd != REG CMD BASE1) { 
init drive(&wini [w next drive+2], 
base cmd, base ctl, irq, 1, irq hook, 2); 
init drive(&wini [w next drive+3], 
base cmd, base ctl, irq, 1, irq hook, 3); 
if (w pci debug) 
printfCCatapci %d: 0x%x 0x%x irq %dAn",devind,base cmd,base ctl,irq); 
} else printf("atapci: ignored drives on secondary %x\n", base cmd); 
} 


w_next_drive += 4; 


PRIVATE int w_do_open(dp, m_ptr) 
struct driver *dp; 

message *m_ptr; 

{ 


/* Abertura de dispositivo: Inicializa a controladora e lê a tabela de partição. */ 


struct wini *wn; 
if (w prepare(m ptr->DEVICE) == NIL DEV) return(ENXIO); 
wn = w wn; 


/* Se testamos antes e falhou, não testa novamente. */ 
if (wn->state & IGNORING) return ENXIO; 
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12535 

12536 /* Se ainda não identificamos ou apresentou defeito, 

12537 * (reJidentifica. 

12538 */ 

12539 if (!(wn->state & IDENTIFIED) || Cwn->state & DEAF)) { 

12540 /* Tenta identificar o dispositivo. */ 

12541 if (w identifyO != OK) { 

12542 if (wn->state & DEAF) w reset()D; 

12543 wn->state = IGNORING; 

12544 return(ENXIO); 

12545 } 

12546 /* Realiza uma transação de teste, a não ser que seja uma unidade de CD (então, 
12547 * podemos acreditar na controladora e um teste pode falhar 

12548 * devido ao fato de não haver nenhum CD na unidade). Se falhar, ignora 
12549 * o dispositivo para sempre. 

12550 */ 

12551 if (!(wn->state & ATAPI) && w io test() != OK) { 

12552 wn->state |= IGNORING; 

12553 return(ENXIO) ; 

12554 } 

12555 } 

12556 

12557 /* Se não for um dispositivo ATAPI, então não abre com RO BIT. */ 

12558 if (!(wun->state & ATAPI) && (m ptr->COUNT & RO BIT)) return EACCES; 

12559 

12560 /* Particiona a unidade de disco, se estiver sendo aberta pela primeira vez 
12561 * ou sendo aberta após ser fechada. 

12562 */ 

12563 if (wun->open ct == 0) 1 

12564 

12565 /* Particiona o disco. */ 

12566 memset(wn->part, sizeof(wn->part), 0); 

12567 memset(wn->subpart, sizeof(wn->subpart), 0); 

12568 partition(êw dtab, w drive * DEV PER DRIVE, P PRIMARY, wn->state & ATAPI); 
12569 } 

12570 wn->open ct++; 

12571 return(OK); 

12572 } 

12574 /*==============2 
12575 : w_prepare la 
12576 ss 
12577 PRIVATE struct device *w prepare(int device) 

12578 { 


12579 /* Prepara para E/S em um dispositivo. */ 
12580 struct wini *prev wn; 
12581 prev_wn = wwn; 


12582 w_device = device; 

12583 

12584 if (device < NR_MINORS) { /* do, dOp[0-3], dl, ... */ 

12585 w drive = device / DEV PER DRIVE; /* salva o número da unidade de disco */ 
12586 w_wn = &winilw drive]; 

12587 w dv = &w wn->part[device % DEV PER DRIVE]; 


12588 } else 
12589 if (Cunsigned) (device -= MINOR dOp0s0) < NR SUBDEVS) 1/*d[0-7]p[0-3]s[0-3]*/ 


12590 w drive = device / SUB PER DRIVE; 
12591 w wn = &winilw drive]; 
12592 w dv = &w wn->subpart[device % SUB PER DRIVE]; 


12593 } else { 
12594 w_device = -1; 
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12595 return(NIL DEV); 

12596 

12597 return(w dv); 

12598 } 

12600  /%====================D=>=>=D=DD=D=DD==D>D=2>D=D=2===2=>==>D>>=>=>==>==>===>=========>======== * 
12601 w identify e 
12602 FEEDS EESC S SS OSCE SS S= ESSES 
12603 PRIVATE int w identifyQO 

12604 1 

12605 /* Descobre se um dispositivo existe, se é um disco AT antigo ou uma unidade de disco ATA 
12606 * mais recente, um dispositivo de mídia removível etc. 

12607 */ 

12608 

12609 struct wini *wn = w wn; 

12610 struct command cmd; 

12611 inti,s; 

12612 unsigned long size; 

12613 #define id byte(n) C&tmp buf[2 * (n)]) 

12614 &define id word(n) (CC(ul6 t) id byte(n)[0] << 0) N 

12615 |(Cu16 t) id byte(n)[1] << 8)) 

12616 ádefine id Tongword(n) (((u32 t) id byte(n)[0] << 0) N 

12617 [CCu32 +) id byte(n) [1] << 8) \ 

12618 [CCu32 +) id byte(n) [2] << 16) N 

12619 | C(u32_t) id byte(n) [3] << 24)) 

12620 

12621 /* Tenta identificar o dispositivo. */ 

12622 cmd.ldh = wn->Tdhpref; 

12623 cmd.command = ATA IDENTIFY; 

12624 if (com simple(&cmd) == OK) 1 

12625 /* This is an ATA device. */ 

12626 wn->state |= SMART; 

12627 

12628 /* Informações do dispositivo. */ 

12629 if ((s=sys insw(wun->base cmd + REG DATA, SELF, tmp buf, SECTOR SIZE)) != OK) 
12630 panic(w name(),"Call to sys inswO) failed", s); 

12631 

12632 /* Por que as strings têm o byte trocado??? */ 

12633 for Ci = 0; i < 40; i++) wid string[i] = id byte(Q7)[i"1]; 

12634 

12635 /* Modo de transformação CHS preferido. */ 

12636 wn->pcylinders = id word(1); 

12637 wn->pheads = id word(3); 

12638 wn->psectors = id word(6); 

12639 size = (u32 t) wn->pcylinders * wn->pheads * wn->psectors; 

12640 

12641 if (Cid byte(49)[1] & 0x02) && size > 512L*1024*2) 1 

12642 /* A unidade de disco é capaz de LBA e é suficientemente grande para 
12643 * confiar que não vai ocorrer confusão. 

12644 */ 

12645 wn->ldhpref |= LDH LBA; 

12646 size = id longword(60); 

12647 

12648 if (w 1ba48 && (Cid word(83)) & (IL << 10))) 1 

12649 /* A unidade de disco é capaz de LBA48 (e LBA48 está ativado). */ 
12650 if Cid word(102) || id word(103)) { 

12651 /* Se o nº de setores não couber em 32 bits, 
12652 * trunca nisso. Portanto, é LBA32 por enquanto. 
12653 * Contudo, isso ainda pode endereçar dispositivos de 


12654 * até 2TB. 
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12655 
12656 
12657 
12658 
12659 
12660 
12661 
12662 
12663 
12664 
12665 
12666 
12667 
12668 
12669 
12670 
12671 
12672 
12673 
12674 
12675 
12676 
12677 
12678 
12679 
12680 
12681 
12682 
12683 
12684 
12685 
12686 
12687 
12688 
12689 
12690 
12691 
12692 
12693 
12694 
12695 
12696 
12697 
12698 
12699 
12700 
12701 
12702 
12703 
12704 
12705 
12706 


12708 
12709 
12710 
12711 
12712 
12713 
12714 


rá 
size = ULONG MAX; 
} else { 
/* O número de setores atual cabe em 32 bits. */ 
size = id_longword(100); 
} 


wn->lba48 = 1; 
} 


if (wn->lcylinders == 0) { 
/* Nada de parâmetros da BIOS? Então, compõe alguns. */ 
wn->1cylinders = wn->pcylinders; 
wn->lheads = wn->pheads; 
wn->Tsectors = wn->psectors; 
while (wn->lcylinders > 1024) 1 
wn->lheads *= 2; 
wn->lcylinders /= 2; 


} 
} else { 
/* Não é um dispositivo ATA; nenhuma transformação, nenhum recurso especial. Não 
* mexa, a não ser que a BIOS saiba disso. 
*/ 
if (wn->lcylinders == 0) { return(ERR); } /* nada de parâmetros da BIOS */ 
wn->pcylinders = wn->lcylinders; 
wn->pheads = wn->lheads; 
wn->psectors = wn->lsectors; 
size = (u32_t) wn->pcylinders * 


wn->pheads * wn->psectors; 


} 


/* Tamanho da unidade de disco inteira */ 
wn->part[0].dv_size = mul64u(size, SECTOR SIZE); 


/* Reconfigura/calibra (onde necessário) */ 

if (w specifyO != OK & w specifyO != OK) 1 
return(ERR); 

} 


if (wn->irq == NO_IRQ) { 
/* Tudo parece ok; registra o IRQ para interromper a consulta seqüencial. */ 
wn->irq = w_drive < 2 ? AT WINI O IRQ : AT_WINI_1_IRQ; 
wn->irq_hook_id = wn->irq; /* id a ser retornada se ocorrer interrupção */ 
if ((s=sys irqsetpolicy(wn->irq, IRQ REENABLE, &wn->irq hook id)) != OK) 
panic(w name), "couldn't set IRQ policy", s); 
if ((s=sys irgenable(&wun->irq hook id)) != OK) 
panic(w name), "couldn't enable IRQ line", s); 


} 
wn->state |= IDENTIFIED; 
return(0K); 


PRIVATE char *w_name() 

{ 

/* Retorna um nome para o dispositivo corrente. */ 
static char name[] = "AT-DO"; 
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12715 
12716 
12717 
12718 


12720 
12721 
12722 
12723 
12724 
12725 
12726 
12727 
12728 
12729 
12730 
12731 
12732 
12733 
12734 
12735 
12736 
12737 
12738 
12739 
12740 
12741 
12742 
12743 
12744 
12745 
12746 
12747 
12748 
12749 
12750 
12751 
12752 
12753 
12754 
12755 
12756 
12757 
12758 
12759 
12760 
12761 
12762 
12763 
12764 
12765 
12766 
12767 
12768 
12769 
12770 


} 


/* 


name[4] = "0" + w drive; 
return name; 


PRIVATE int w_io_test(void) 


{ 


int r, save_dev; 

int save_timeout, save_errors, save_wakeup; 
iovec_t iov; 

static char buf[SECTOR_SIZE] ; 

iov.iov_addr = (vir_bytes) buf; 
iov.iov_size = sizeof(buf); 

save_dev = w_device; 


/* Reduz os valores de tempo limite para esta transação de teste. */ 
save timeout = timeout ticks; 

save errors = max errors; 

save wakeup = wakeup ticks; 


if (lw standard timeouts) 1 
timeout ticks = HZ * 4; 
wakeup ticks = HZ * 6; 

max errors = 3; 


} 


w_testing = 1; 


/* Tenta E/S na unidade de dispositivo real (não em qualquer (sub)partição). * 


if (w prepare(w drive * DEV PER DRIVE) == NIL DEV) 
panic(w name), "Couldn't switch devices", NO NUM); 


r = w transfer(SELF, DEV GATHER, 0, &iov, 1); 


/* Troca de volta. */ 
if (w prepare(save dev) == NIL DEV) 
panic(w name), "“Couldn't switch back devices", NO NUM); 


/* Restaura parâmetros. */ 
timeout ticks = save timeout; 
max errors = save errors; 
wakeup ticks = save wakeup; 
w testing = 0; 


/* Testa se tudo funcionou. */ 

if Cr != OK || iov.iov size != 0) 1 
return ERR; 

} 


/* Tudo funcionou. */ 


return OK; 
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12772 
12773 
12774 
12775 
12776 
12777 
12778 
12779 
12780 
12781 
12782 
12783 
12784 
12785 
12786 
12787 
12788 
12789 
12790 
12791 
12792 
12793 
12794 
12795 
12796 
12797 
12798 
12799 
12800 
12801 
12802 
12803 
12804 
12805 
12806 
12807 
12808 
12809 


12811 
12812 
12813 
12814 
12815 
12816 
12817 
12818 
12819 
12820 
12821 
12822 
12823 
12824 
12825 
12826 
12827 
12828 
12829 
12830 
12831 


PRIVATE int w specifyO 


{ 


/* Rotina para inicializar ou reconfigurar unidade de disco */ 


struct wini *wn = w wn; 
struct command cmd; 


if ((wn->state & DEAF) && w_resetO != OK) { 
return(ERR); 
} 


if (!(wn->state & ATAPI)) { 
/* Especifica parâmetros: compensação prévia, número de cabeçotes e setores. 
cmd.precomp = wn->precomp; 
cmd.count = wn->psectors; 
cmd. 1dh = w_wn->ldhpref | (wn->pheads - 1); 
cmd.command = CMD_SPECIFY; /* Especifica alguns parâmetros */ 


/* Saída de bloco de comandos e vê se a controladora aceita os parâmetros. */ 
if (com simple(&cmd) != OK) return(ERR); 


if (!(wn->state & SMART)) { 
/* Calibra um disco antigo. */ 
cmd.sector = 0; 
cmd.cyl_lo = 0; 
cmd.cyl_hi = 0; 
cmd. 1dh = w_wn->ldhpref; 
cmd.command = CMD_RECALIBRATE; 


if (com_simple(&cmd) != OK) return(ERR); 
} 
} 
wn->state |= INITIALIZED; 
return(0K); 


PRIVATE int do_transfer(struct wini *wn, unsigned int precomp, unsigned int count, 


{ 


unsigned int sector, unsigned int opcode) 


struct command cmd; 
unsigned secspcyl = wn->pheads 


* wn->psectors; 

cmd.precomp = precomp; 

cmd.count = count; 

cmd.command = opcode == DEV_SCATTER ? CMD_WRITE : CMD_READ; 


if (w_1ba48 && wn->1ba48) { 


} else */ 
if (wn->ldhpref & LDH LBA) { 
cmd.sector = (sector >> 0) & OxFF; 


cmd.cyl_lo = (sector >> 8) & OxFF; 

cmd.cyl_hi = (sector >> 16) & 0xFF; 

cmd. 1dh wn->ldhpref | ((sector >> 24) & OxF); 
} else { 


*/ 
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12832 
12833 
12834 
12835 
12836 
12837 
12838 
12839 
12840 
12841 
12842 
12843 


12845 
12846 
12847 
12848 
12849 
12850 
12851 
12852 
12853 
12854 
12855 
12856 
12857 
12858 
12859 
12860 
12861 
12862 
12863 
12864 
12865 
12866 
12867 
12868 
12869 
12870 
12871 
12872 
12873 
12874 
12875 
12876 
12877 
12878 
12879 
12880 
12881 
12882 
12883 
12884 
12885 
12886 
12887 
12888 
12889 
12890 
12891 


int cylinder, head, sec; 
cylinder = sector / secspcyl; 
head = (sector % secspcyl) / wn->psectors; 
sec = sector % wn->psectors; 
cmd.sector = sec + 1; 
cmd.cyl To = cylinder & BYTE; 
cmd.cyl hi = (cylinder >> 8) & BYTE; 
cmd. 1dh = wn->ldhpref | head; 
} 


return com_out(&cmd) ; 


PRIVATE int w_transfer(proc_nr, opcode, position, iov, nr_req) 


int proc_nr; /* processo que faz a requisição */ 

int opcode; /* DEV_GATHER ou DEV SCATTER */ 

off t position; /* deslocamento no dispositivo a ler ou escrever*/ 
iovec t *iov; / 

unsigned nr reg; Pá 


{ 


* comprimento do vetor de requisição */ 


struct wini *wn = wwn; 

iovec t *iop, *iov end = iov + nr req; 

int r, s, errors; 

unsigned long block; 

unsigned long dv size = cv64ul(w dv->dv size); 
unsigned cylinder, head, sector, nbytes; 


/* Verifica endereço de disco. */ 
if (Cposition & SECTOR MASK) != 0) return(EINVAL); 


errors = 0; 


while (nr req > 0) 1 
/* Quantos bytes vai transferir? */ 
nbytes = 0; 
for (Ciop = iov; iop < iov end; iop++) nbytes += iop->iov size; 
if (C(nbytes & SECTOR MASK) != 0) return(EINVAL); 


/* Que bloco no disco e como vai fechar em EOF? */ 

if (position >= dv size) return(OK); /* At EOF */ 
if (position + nbytes > dv size) nbytes = dv size - position; 
block = div64u(add64ul (w dv->dv base, position), SECTOR SIZE); 


if (nbytes >= wn->max count) 1 


/* A unidade de disco não pode fazer mais do que max count de uma vez. 


nbytes = wn->max count; 


} 


/* Primeiro verifica se uma reinicialização é necessária. */ 
if (!(wn->state & INITIALIZED) && w_specify© != OK) return(EIO); 


/* Diz à controladora para que transfira nbytes bytes. */ 
r = do_transfer(wn, wn->precomp, ((nbytes >> SECTOR_SHIFT) & BYTE), 
block, opcode); 


while (r == OK && nbytes > 0) { 
/* Para cada setor, espera por uma interrupção e busca os dados 


* ponteiro para vetor de pedido de leitura ou escrita */ 


*/ 
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12892 
12893 
12894 
12895 
12896 
12897 
12898 
12899 
12900 
12901 
12902 
12903 
12904 
12905 
12906 
12907 
12908 
12909 
12910 
12911 
12912 
12913 
12914 
12915 
12916 
12917 
12918 
12919 
12920 
12921 
12922 
12923 
12924 
12925 
12926 
12927 
12928 
12929 
12930 
12931 
12932 
12933 
12934 
12935 
12936 
12937 
12938 
12939 
12940 
12941 
12942 


12944 
12945 
12946 
12947 
12948 
12949 
12950 
12951 


* (leitura), ou fornece dados para a controladora e espera por uma 
* interrupção (escrita). 


ni 


if (opcode == DEV GATHER) { 
/* Primeiro uma interrupção, depois dados. */ 
if (Cr = at intr vaitO) != OK) { 
/* Um erro, envia dados para um sumidouro de bits. */ 
if (w wn->w status & STATUS DRQ) { 
if ((s=sys insw(wun->base cmd + REG DATA, SELF, tmp buf, SECTOR SIZE)) != OK) 
panic(w name(),"Call to sys inswO) failed", s); 
} 


break; 


} 


/* Espera pela transferência de dados solicitada. */ 
if (lw waitfor(STATUS DRQ, STATUS DRQ)) { r = ERR; break; + 


/* Copia bytes no (ou do) buffer do dispositivo. */ 
if (opcode == DEV GATHER) { if((s=sys insw(wn->base cmd+REG DATA, 
proc nr, (void*)iov->iov addr, SECTOR SIZE)) !=0K) 
panic(w name(),"Call to sys inswO) failed", s); 
} else { if((s=sys outsw(wn->base cmd+REG DATA, proc nr, 
(void *) iov->iov addr,SECTOR SIZE)) !=OK) 
panic(w name(),"Call to sys inswO) failed", s); 


/* Dados enviados, espera por uma interrupção. */ 
if (Cr = at intr waitO) != OK) break; 
} 


/* Registra os bytes transferidos com sucesso. */ 

nbytes -= SECTOR SIZE; 

position += SECTOR SIZE; 

iov->iov addr += SECTOR SIZE; 

if (Ciov->iov size -= SECTOR SIZE) == 0) { iov++; nr req--; 5 
} 


/* Houve erros? */ 
if (r != 0K) { 


/* Não retenta se setor foi marcado como defeituoso ou se ocorrem erros demais. 


if (r == ERR_BAD_SECTOR || ++errors == max_errors) { 
w_command = CMD_IDLE; 


return(EIO); 
} 
} 
} 
w_command = CMD_IDLE; 
return(0K); 

} 

/* === ¥ 
kid com out * 
BODDDDDDDDDDDDDDDD>DDD>D0>>D>>>0=>>>>>D0=>>=>>>>"0=>>D>>"0=>>>>>>==>>>>>>=>=>>>>===* / 

PRIVATE int com out(cmd) 

struct command “cmd; /* Bloco de comandos */ 


{ 


/* Saída do bloco de comandos para a controladora da winchester e retorna o status */ 


*/ 


748 SISTEMAS OPERACIONAIS 


12952 struct wini *wn = w wn; 

12953 unsigned base cmd = wn->base cmd; 

12954 unsigned base ct] = wn->base ctl; 

12955 pvb pair t outbyte[7]; /* vector for sys voutb(O) */ 
12956 int s; /* status de sys_(v)outb() */ 
12957 

12958 if (w_wn->state & IGNORING) return ERR; 

12959 

12960 if (!w_waitfor(STATUS_BSY, 0)) { 

12961 printf("%s: controller not ready\n", w nameO); 

12962 return(ERR); 

12963 } 

12964 


12965 /* Seleciona unidade de disco. */ 
12966 if ((s=sys outb(base cmd + REG LDH, cmd->ldh)) != OK) 


12967 panic(w name(),"Couldn't write register to select drive",s); 

12968 

12969 if Clw waitfor(STATUS BSY, 0)) { 

12970 printfC"%s: com out: drive not readyn", w name); 

12971 return(ERR); 

12972 

12973 

12974 /* Escalona uma tarefa para despertar, algumas controladoras são manhosas. Isso é feito com 
12975 * um alarme síncrono. Se um tempo limite ocorre, uma mensagem SYN ALARM é enviada 
12976 * de HARDWARE, para que w intr wait() possa chamar w timeout() no caso de a 

12977 * controladora não ter sido capaz de executar o comando. Os tempos limites restantes são 
12978 * simplesmente ignorados pelo laço principal. 

12979 */ 

12980 sys setalarm(wakeup ticks, 0); 

12981 

12982 wn->w status = STATUS ADMBSY; 

12983 w command = cmd->command; 


12984 pv set(outbyte[0], base ct] + REG CTL, wn->pheads >= 8 ? CTL EIGHTHEADS : 0); 
12985 pv set(outbyte[1], base cmd + REG PRECOMP, cmd->precomp) ; 

12986 pv set(outbyte[2], base cmd + REG COUNT, cmd->count); 

12987 pv set(outbyte[3], base cmd + REG SECTOR, cmd->sector); 

12988 pv set(outbyte[4], base cmd + REG CYL LO, cmd->cy1 10); 

12989 pv set(outbyte[5], base cmd + REG CYL HT, cmd->cy1 hi); 

12990 pv set(outbyte[6], base cmd + REG COMMAND, cmd->command) ; 

12991 if ((s=sys voutb(outbyte,7)) != OK) 

12992 panic(w name(),"Couldn't write registers with sys voutb(O",s); 
12993 return(OK); 

12994 + 


12996  /f==================================>======================================== * 
12997 * w need reset * 
12998 * ===> ¥Ý / 
12999 PRIVATE void w need reset() 

13000 + 

13001 /* A controladora precisa ser reconfigurada. */ 

13002 struct wini *wn; 

13003 int dr = 0; 

13004 

13005 for (wn = wini; wn < &wini [MAX DRIVES]; wn++, dr++) { 

13006 if (wn->base_cmd == w_wn->base_cmd) { 

13007 wn->state |= DEAF; 

13008 wn->state &= “INITIALIZED; 

13009 } 

13010 } 

13011 } 
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13013 /*======== n * 
13014 x w do close * 
13015 * === * / 


13016 PRIVATE int w do close(dp, m ptr) 

13017 struct driver *dp; 

13018 message “*m ptr; 

13019 { 

13020 /* Fechamento de dispositivo: Libera dispositivo. */ 
13021 if (w prepare(m ptr->DEVICE) == NIL DEV) 


13022 return(ENXIO) ; 

13023 w wn->open ct--; 

13024 return(OK); 

13025 + 

13027 /f======D=D=D=D=D==>=D=D=D2==2==2==D=D=D2==2==2>====>=02==2=>==>=>==2==2====>=>=========== * 
13028 * com simple * 
13029 * === * / 
13030 PRIVATE int com simple(Ccmd) 

13031 struct command *cmd; /* Bloco de comandos */ 

13032 { 


13033 /* Um comando de controladora simples, apenas uma interrupção e nenhuma fase de dados */ 
13034 int rs 

13035 

13036 if (w wn->state & IGNORING) return ERR; 

13037 

13038 if (Cr = com out(cmd)) == OK) r = at intr waitO; 

13039 w command = CMD IDLE; 

13040 return(r); 


13041 3 

13043 /f=================D=>=>=D==>=D=D=DDD=>=DD>>=D>D=>D2>==2=>=>=2=>=>>==>>==>===>===>=============== * 
13044 5 w timeout i 
13045  #===== ~) 
13046 PRIVATE void w_timeout(void) 

13047 {£ 

13048 struct wini *wn = wwn; 

13049 

13050 switch (w_command) { 

13051 case CMD IDLE: 

13052 break; /* fine */ 


13053 case CMD READ: 
13054 case CMD WRITE: 


13055 /* Impossível, mas não em PCs: A controladora não responde. */ 

13056 

13057 /* Limitar a E/S de vários setores parece ajudar. */ 

13058 if (wn->max count > 8 * SECTOR SIZE) { 

13059 wn->max count = 8 * SECTOR SIZE; 

13060 } else { 

13061 wn->max_count = SECTOR_SIZE; 

13062 } 

13063 /*FALHA*/ 

13064 default: 

13065 /* Algum outro comando. */ 

13066 if (w testing) wn->state |= IGNORING;  /* Jogue esta unidade de disco fora. */ 
13067 else if (!lw silent) printf("%s: timeout on command %02x\n", w name), w command); 
13068 w need reset(); 

13069 wn->w status = 0; 

13070 


13071 + 
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13073 
13074 
13075 
13076 
13077 
13078 
13079 
13080 
13081 
13082 
13083 
13084 
13085 
13086 
13087 
13088 
13089 
13090 
13091 
13092 
13093 
13094 
13095 
13096 
13097 
13098 
13099 
13100 
13101 
13102 
13103 
13104 
13105 
13106 
13107 
13108 
13109 
13110 
13111 
13112 
13113 
13114 
13115 
13116 
13117 
13118 


13120 
13121 
13122 
13123 
13124 
13125 
13126 
13127 
13128 
13129 
13130 
13131 


PRIVATE int w reset() 

{ 

/* Executa uma reconfiguração na controladora. Isso é feito após qualquer catástrofe, 
* como a controladora se recusando a responder. 

*/ 
ints; 
struct wini *wn = w wn; 


/* Não se incomoda se essa unidade de disco é esquecida. */ 
if (w_wn->state & IGNORING) return ERR; 


/* Espera por qualquer recuperação de unidade de disco interna. */ 
tickdelay (RECOVERY TICKS); 


/* Bit de reconfiguração de strobe */ 
if ((s=sys outb(wn->base ct] + REG CTL, CTL RESET)) != OK) 
panic(w name(),"Couldn't strobe reset bit",s); 
tickdelay(DELAY TICKS); 
if ((s=sys outb(wn->base ct] + REG CTL, 0)) != OK) 
panic(w name(),"Couldn't strobe reset bit",s); 
tickdelay(DELAY TICKS); 


/* Espera que a controladora fique pronta */ 

if (lw waitfor(STATUS BSY, 0)) É 
printfC"%s: reset failed, drive busy\n", w name); 
return(ERR); 

} 


/* Reg. de erro deve ser testado agora, mas algumas unidades de disco bagunçam isso. * 


for (wn = wini; wn < &wini [MAX DRIVES]; wn++) { 
if (wn->base_cmd == w_wn->base_cmd) { 
wn->state &= “DEAF; 
if (w_wn->irq_need_ack) { 
/* Certifica-se de que o irq está realmente ativado.. */ 
sys_irqenable(&w_wn->irq_hook_id); 


return(0K); 


PRIVATE void w intr waitO 
{ 


/* Espera pela interrupção do término de uma tarefa. */ 
message m; 
if (w_wn->irq != NO IRQ) { 


/* Espera por uma interrupção que configura w_status como "not busy". */ 
while (w_wn->w_status & (STATUS_ADMBSY | STATUS_BSY)) { 
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13132 
13133 
13134 
13135 
13136 
13137 
13138 
13139 
13140 
13141 
13142 
13143 
13144 
13145 
13146 
13147 


13149 
13150 
13151 
13152 
13153 
13154 
13155 
13156 
13157 
13158 
13159 
13160 
13161 
13162 
13163 
13164 
13165 
13166 
13167 
13168 
13169 
13170 
13171 
13172 


13174 
13175 
13176 
13177 
13178 
13179 
13180 
13181 
13182 
13183 
13184 
13185 
13186 
13187 
13188 
13189 
13190 
13191 


receive(ANY, &m); /* mensagem HARD INT esperada */ 
if C(m.m type == SYN ALARM) { /* mas verifica tempo limite */ 
w timeout O ; /* a.o. set w status */ 


} else if (m.m type == HARD INT) { 
sys inb(w wn->base cmd + REG STATUS, &w wn->w status); 
ack irqs(m.NOTIFY ARG); 
} else { 
printfC"AT WINI got unexpected message %d from %d\n", 
m.m type, m.m source); 


; 

} else { 
/* Interrupção ainda não alocada; usa consulta seqüencial. */ 
(void) w waitfor(STATUS BSY, 0); 


PRIVATE int at intr waitO 

{ 

/* Espera por uma interrupção, verifica os bits de status e retorna erro/sucesso. */ 
int r; 
int s,inbval; /* 1ê valor com sys inb */ 


wintr wvaitO; 
if C(w wn->w status & (STATUS BSY | STATUS WF | STATUS ERR)) == 0) { 
r= 0; 
} else { 
if ((s=sys_inb(w_wn->base_cmd + REG ERROR, &inbval)) != OK) 
panic(w name(),"Couldn't read register",s); 
if (C(w wn->w status & STATUS ERR) && (inbval & ERROR BB)) 1 


r = ERR BAD SECTOR; /* setor defeituoso, novas tentativas não ajudam */ 
} else { 
r = ERR; /* qualquer outro erro */ 
} 
} 
w_wn->w_status |= STATUS_ADMBSY; /* presume que ainda está ocupado com E/S */ 
return(r); 
} 
$ w_waitfor i 
X === ¥ / 
PRIVATE int w_waitfor(mask, value) 
int mask; /* máscara de status */ 
int value; /* status exigido */ 


{ 

/* Espera até que a controladora esteja no estado exigido. Retorna zero no tempo limite. 
* Um alarme que ativou um flag de tempo limite é usado. TIMEOUT é em micros, precisamos de 
* tiques. Não é necessário desativar o alarme, pois um flag estático é usado 


* e um tempo limite restante não pode causar danos. 
clock t t0, tl; 
int 's; 
getuptime(&tO); 
do 1 
if ((s=sys inb(w wn->base cmd + REG STATUS, &w wn->w status)) != OK) 
panic(w name(),"Couldn't read register",s); 
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13192 
13193 
13194 
13195 
13196 
13197 
13198 
13199 
13200 


13202 
13203 
13204 
13205 
13206 
13207 
13208 
13209 
13210 
13211 
13212 
13213 
13214 
13215 
13216 
13217 
13218 
13219 


13221 
13222 
13223 
13224 
13225 
13226 
13227 
13228 
13229 
13230 
13231 
13232 
13233 
13234 
13235 
13236 
13237 
13238 
13239 
13240 
13241 
13242 
13243 
13244 
13245 
13246 
13247 
13248 
13249 
13250 
13251 


if ((w wn->w status & mask) == value) { 
return 1; 


} 


} while ((s=getuptime(&t1)) == OK && (t1-t0) < timeout_ticks ); 
if (OK != s) printf("AT_WINI: warning, get uptime failed: %d\n",s); 


w_need_reset(); /* a controladora deu defeito */ 
return(0); 
} 
JEn a 
$ w_geometry * 
k 
PRIVATE void w_geometry(entry) 
struct partition *entry; 
{ 
struct wini *wn = wwn; 
if (wn->state & ATAPI) { /* constroi alguns números */ 
entry->cylinders = div64u(wn->part[0].dv_size, SECTOR_SIZE) / (64*32); 
entry->heads = 64; 
entry->sectors = 32; 
} else { /* Retorna a geometria lógica. */ 
entry->cylinders = wn->lcylinders; 
entry->heads = wn->lheads; 
entry->sectors = wn->lsectors; 
} 
/¥ === * 
i w_other i 
EDDDSDSDSDSD=DSDDDDDDDSSDDSSDD============================================= * / 


PRIVATE int w other(dr, m) 
struct driver “dr; 
message *m; 


{ 


int r, timeout, prev; 


if (m->m_type != DEV_IOCTL ) { 
return EINVAL; 
} 


if (m->REQUEST == DIOCTIMEOUT) { 
if (Cr=sys datacopy(m->PROC NR, (vir_bytes)m->ADDRESS, 
SELF, (vir bytes)&timeout, sizeof(timeout))) != OK) 
return r; 


if (timeout == 0) { 
/* Restaura os padrões. */ 
timeout ticks = DEF TIMEOUT TICKS; 
max errors = MAX ERRORS; 
wakeup ticks = WAKEUP; 
w silent = 0; 
+ else if (timeout < 0) { 
return EINVAL; 
} else { 
prev = wakeup_ticks; 


if (lw standard timeouts) { 
/* Configura tempo limite (inferior), reduz tolerância de 
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13252 * erro inferior e configura modo silencioso. 
13253 hd 

13254 wakeup ticks = 
13255 max errors = 3; 
13256 w silent = 1; 
13257 

13258 if (timeout ticks > timeout) 

13259 timeout ticks = timeout; 

13260 } 

13261 

13262 if (Cr=sys datacopy(SELF, (vir_bytes)&prev, 

13263 m->PROC NR, (vir bytes)m->ADDRESS, sizeof(prev))) !=OK) 
13264 return r; 

13265 } 

13266 

13267 return OK; 

13268 } else if (m->REQUEST == DIOCOPENCT) { 

13269 int count; 

13270 if (w prepare(m->DEVICE) == NIL DEV) return ENXIO; 

13271 count = w wn->open ct; 

13272 if (Cr=sys datacopy(SELF, (vir bytes)&count, 

13273 m->PROC NR, (vir bytes)m->ADDRESS, sizeof(count))) != OK) 
13274 return r; 

13275 return OK; 

13276 

13277 return EINVAL; 

13278 } 


timeout; 


13280 /*¥==== 
13281 * w hw int * 
13282 POSSE Eee / 
13283 PRIVATE int w hw int(dr, m) 

13284 struct driver *dr; 

13285 message *m; 


13286 { 

13287 /* Interrupção(ões) restantes recebidas; reconhece. */ 

13288 ack irqs(m->NOTIFY ARG); 

13289 

13290 return OK; 

13291 + 

13294 

13295 

13296 

13297 PRIVATE void ack irqs(unsigned int irqs) 

13298 { 

13299 unsigned int drive; 

13300 for (drive = 0; drive < MAX DRIVES && irqs; driver) 1 

13301 if (1 (wini[drive].state & IGNORING) && winildrive].irq need ack && 
13302 (wini [drive] .irq mask & irgs)) { 

13303 if (sys inb((wini [drive].base cmd+REG STATUS), &wini [drive] .w status) !=0K) 
13304 printfC"couldn't ack irq on drive %d\n", drive); 
13305 if (sys irgenable(&wini [drive]. irq hook id) != OK) 

13306 printfC"couldn't re-enable drive %d\n", drive); 
13307 irgs &= “winildrive].irq mask; 

13308 } 

13309 } 


13310 + 
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13313 &define STSTR(a) if (status & STATUS ## a) { strcat(str, £a); strcat(str, " "5: 5 
13314 #define ERRSTR(a) if (e & ERROR ## a) { strcat(str, da); strcat(str, " "); 5 
13315 char *strstatus(int status) 
13316 { 

13317 static char str[200]; 
13318 str[0] = “N0": 

13319 

13320 STSTR(BSY); 

13321 STSTR(DRDY) ; 

13322 STSTR(DMADF) ; 

13323 STSTR(SRVCDSC) ; 

13324 STSTR(DRQ) ; 

13325 STSTR(CORR); 

13326 STSTR(CHECK) ; 

13327 return str; 

13328 + 

13330 char *strerr(int e) 

13331 { 

13332 static char str[200]; 
13333 str[0] = "10"; 

13334 

13335 ERRSTR(BB); 

13336 ERRSTR(ECC) ; 

13337 ERRSTR(ID); 

13338 ERRSTR(AC) ; 

13339 ERRSTRCTK); 

13340 ERRSTR(DM) ; 

13341 

13342 return str; 

13343 + 


AAA ++ 
drivers/tty/tty.h 
HHHEHEHHHHHHH HH RO DO HHHH HHHH HHHH HHHH HH HHHH HHHH O O DD +H O O DO OO OO O O O 


13400 /* tty.h - Terminais */ 
13401 

13402 #include <timers.h> 

13403 


13404 /* Primeiros números secundários para as várias classes de dispositivos TTY. */ 
13405 #define CONS_MINOR 0 


13406 gdefine LOG MINOR 15 

13407 #define RS232 MINOR 16 

13408 #define TTYPX MINOR 128 

13409 #define PTYPX MINOR 192 

13410 

13411 #define LINEWRAP 1 /* console.c - mudança automática de linha na coluna 80 */ 
13412 

13413 #define TTY_IN_BYTES 256 /* tamanho da fila de entrada do tty */ 

13414 #define TAB SIZE 8 /* distância entre pontos de tabulação */ 
13415 &define TAB MASK 7 /* máscara p/ calcular posição de tabulação */ 
13416 

13417 &define ESC 'N33º /* escape */ 

13418 

13419 define O NOCTTY 00400 /* de <fcntl.h> ou cc engasgará */ 
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13420 
13421 
13422 
13423 
13424 
13425 
13426 
13427 
13428 
13429 
13430 
13431 
13432 
13433 
13434 
13435 
13436 
13437 
13438 
13439 
13440 
13441 
13442 
13443 
13444 
13445 
13446 
13447 
13448 
13449 
13450 
13451 
13452 
13453 
13454 
13455 
13456 
13457 
13458 
13459 
13460 
13461 
13462 
13463 
13464 
13465 
13466 
13467 
13468 
13469 
13470 
13471 
13472 
13473 
13474 
13475 
13476 
13477 
13478 
13479 


define O NONBLOCK 04000 


struct tty; 
typedef | PROTOTYPE( int (*devfun t), (struct tty *tp, int try only) ); 
typedef | PROTOTYPE( void (*devfunarg t), (struct tty *tp, int O ); 


typedef struct tty { 
int tty_events; /* configurado quando TTY deve inspecionar esta linha */ 
int tty_index; /* índice para tabela TTY */ 
int tty_minor; /* número secundário do dispositivo */ 


/* Fila de entrada. Os caracteres digitados são armazenados aqui até ficarem prontos */ 
ul6 t *tty_inhead; /* ponteiro para onde o próximo caracter ficará */ 

ul6 t *tty intail; /* ponteiro para o próximo caracter a ser fornecido para o prog */ 
int tty incount; /* nº de caracteres na fila de entrada */ 

int tty eotct; /* número de "quebras de linha " na fila de entrada */ 
devfun t tty devread; /* rotina para ler os buffers de baixo nível */ 

devfun t tty icancel; /* cancela qualquer entrada de dispositivo */ 

int tty min; /* nº mínimo de caracteres solicitados na fila de entrada */ 
timer t tty tmr; /* o temporizador desse tty */ 


/* Seção de saída. */ 

devfun t tty devwrite; 
devfunarg t tty echo; 

devfun t tty ocancel; 

devfun t tty break; 


* rotina para iniciar a saída do dispositivo real */ 

* rotina para ecoar a entrada de caracteres */ 

* cancela qualquer saída de dispositivo em andamento */ 
permite que o dispositivo envie uma quebra */ 


x3 


/* Parâmetros e status de terminal. */ 

int tty position; /* posição corrente na tela para ecoar */ 

char tty reprint; /* 1 quando a entrada ecoada ficou bagunçada, senão O */ 
char tty escaped; /* 1 quando LNEXT (^V) acabou de ser visto, senão O */ 

char tty inhibited; /* 1 quando STOP (^S) acabou de ser visto (interrompe a saída) */ 
char tty pgrp; /* número de entrada do processo de controle */ 

char tty openct; /* contador do número de aberturas desse tty */ 


/* As informações sobre requisições de E/S incompletas são armazenadas aqui. */ 


char tty inrepcode; /* código de resposta, TASK REPLY ou REVIVE */ 

char tty inrevived; /* configura como 1 se callback de reanimação estiver pendente */ 
char tty incaller; /* processo que fez a chamada (normalmente, o SA) */ 

char tty inproc; /* processo que quer ler do tty */ 

vir bytes tty in vir; /* endereço virtual onde devem ficar os dados */ 

int tty inleft; /* quantos caracteres ainda são necessários */ 

int tty incum; /* nº de caracteres inseridos até aqui */ 

char tty outrepcode; /* código de resposta, TASK REPLY ou REVIVE */ 

char tty outrevived; /* configura como 1 se callback de reanimação estiver pendente */ 
char tty outcaller; /* processo que fez a chamada (normalmente, o SA) */ 

char tty outproc; /* processo que quer escrever no tty */ 

vir bytes tty out vir; /* endereço virtual de onde vêm os dados */ 

int tty outleft; /* nº de caracteres ainda a aparecerem na saída */ 

int tty outcum; /* nº de caracteres na saída até aqui */ 

char tty iocaller; /* processo que fez a chamada (normalmente, o SA) */ 

char tty ioproc; /* processo que quer fazer uma operação ioctl */ 

int tty ioreqg; /* código de requisição de ioctl */ 

vir bytes tty iovir; /* endereço virtual do buffer ioctl */ 

/* select(D dados */ 

int tty select ops; /* quais operações são interessantes */ 


int tty select proc; /* qual processo quer notificação */ 


/* Diversos. */ 
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13480 
13481 
13482 
13483 
13484 
13485 
13486 
13487 
13488 
13489 
13490 
13491 
13492 
13493 
13494 
13495 
13496 
13497 
13498 
13499 
13500 
13501 
13502 
13503 
13504 
13505 
13506 
13507 
13508 
13509 
13510 
13511 
13512 
13513 
13514 
13515 
13516 
13517 
13518 
13519 
13520 
13521 
13522 
13523 
13524 
13525 
13526 
13527 
13528 
13529 
13530 
13531 
13532 
13533 
13534 
13535 
13536 
13537 
13538 
13539 


devfun t tty ioctl; 
devfun t tty close; 

void *tty priv; 

struct termios tty termios; 
struct winsize tty winsize; 


configura params. específicos ao disp.*/ 


atributos de terminal */ 


/* 
/* 
/* 
/* 
/* 
a 


ul6 t tty inbuf[TTY IN BYTES] buffer de entrada do tty */ 


} tty_t; 


/* Memória alocada em tty.c; portanto, extern aqui. */ 

extern tty t tty table[NR CONS+NR RS LINES+NR PTYS]; 

extern int ccurrent; /* console correntemente visível */ 
extern int irq hook id; /* id de gancho para irq de teclado */ 


extern unsigned long kbd irq set; 
extern unsigned long rs irq set; 


/* Valores dos campos. */ 
tdefine NOT ESCAPED 
tdefine ESCAPED 


/* o caractere anterior não é LNEXT (CV) */ 
/* o caractere anterior era LNEXT (CV) */ 


0 
1 

tdefine RUNNING 0 /* nenhum STOP (CS) foi digitado para interromper a saída */ 
1 /* STOP (°S) foi digitado para interromper a saída */ 


#define STOPPED 


/* Campos e flags nos caracteres na fila de entrada. */ 


#define IN_CHAR 0x00FF /* os 8 bits inferiores são o próprio caractere */ 
tdefine IN LEN 0x0F00 /* comprimento do car, se tiver sido ecoado */ 
#define IN_LSHIFT 8 /* comprimento = (c & IN_LEN) >> IN_LSHIFT */ 
#define IN_EOT 0x1000 /* o car é uma quebra de linha (°D, LF) */ 

#define IN EOF 0x2000 /* o car é EOF (°D), não retorna para o usuário */ 
gdefine IN ESC 0x4000 /* escape por LNEXT (^V), nenhuma interpretação */ 


/* Tempos e tempos limites. */ 
tdefine force timeout(O) ((void) (0)) 


/* Memória alocada em tty.c; portanto, extern aqui. */ 
extern timer t *tty timers; /* fila de temporizadores de TTY */ 
extern clock t tty next timeout; /* próximo tempo limite de TTY */ 


/* Número de elementos e limite de um buffer. */ 
gdefine buflenCbuf) (sizeof(buf) / sizeof(Cbuf) [0])) 
gdefine bufendCbuf) (Cbuf) + buflenCbuf)) 


/* Memória alocada em tty.c; portanto, extern aqui. */ 
extern struct machine machine; /* informações da máquina (a.o.: pc at, ega) */ 


/* Prototypes de função para driver TTY. */ 


/* tty.c */ 

- PROTOTYPE( void handle events, (struct tty *tp) J 
- PROTOTYPE( void sigchar, (struct tty *tp, int sig) J; 
- PROTOTYPE( void tty task, (void) J: 
- PROTOTYPE( int in process, (struct tty *tp, char *buf, int count) J 
- PROTOTYPE( void out process, (struct tty *tp, char *bstart, char *bpos, 


char *bend, int *icount, int *ocount) Ji 
- PROTOTYPE( void tty_wakeup, (clock t now) Js 
- PROTOTYPE( void tty_reply, (int code, int replyee, int proc nr, 


int status) DD; 
- PROTOTYPE( int tty devnop, (struct tty “tp, int try) Jj; 
- PROTOTYPE( int select try, (struct tty *tp, int ops) J; 


- PROTOTYPE( int select_retry, (struct tty *tp) J5 


informa ao dispositivo que o tty está fechado */ 
ponteiro para dados privados por dispositivo */ 


tamanho da janela (n° de linhas e n° de colunas) */ 
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13541 
13542 
13543 
13544 
13545 
13546 
13547 
13548 
13549 
13550 
13551 
13552 
13553 
13554 
13555 
13556 
13557 
13558 
13559 
13560 
13561 


/* console.c */ 


- PROTOTYPE( void kputc, (int c) J: 
- PROTOTYPE( void cons stop, (void) DE: 
- PROTOTYPE( void do new kmess, (message *m) jz 
- PROTOTYPE( void do diagnostics, (message *m) Jė 
- PROTOTYPE( void scr init, (struct tty *tp) J; 
- PROTOTYPE( void toggle_scroll, (void) J; 
- PROTOTYPE( int con_loadfont, (message *m) Ji 
- PROTOTYPE( void select console, (int cons line) J 
/* keyboard.c */ 

- PROTOTYPE( void kb init, (struct tty *tp) Jo 
- PROTOTYPE( void kb init once, (void) Ji 
- PROTOTYPEC int kbd_loadmap, (message *m) js 
- PROTOTYPE( void do panic dumps, (message *m) Js 
- PROTOTYPE( void do_fkey_ctl, (message *m) Ji 
- PROTOTYPE( void kbd interrupt, (message *m) js 


/* vidcopy.s */ 
- PROTOTYPE( void 
- PROTOTYPE( void 


vid vid copy, (unsigned src, unsigned dst, unsigned count)); 
mem vid copy, (ul6 t *src, unsigned dst, unsigned count)); 


AAA ++ 


drivers/tty/tty.c 
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13600 
13601 
13602 
13603 
13604 
13605 
13606 
13607 
13608 
13609 
13610 
13611 
13612 
13613 
13614 
13615 
13616 
13617 
13618 
13619 
13620 
13621 
13622 
13623 
13624 
13625 
13626 
13627 
13628 
13629 


/* 


* 


* 


E 


Este arquivo contém o driver de terminal, tanto para o console IBM como para 

terminais ASCII normais. Ele manipula apenas a parte independente de dispositivo de um 
TTY; as partes dependentes de dispositivo estão em console.c, rs232.c etc. Este arquivo 
contém dois pontos de entrada principais, tty task() e tty wakeup(D, e vários pontos de 
entrada secundários, para uso pelo código dependente de dispositivo. 


A parte independente de dispositivo aceita entrada do "teclado" da 

parte dependente de dispositivo, realiza processamento de entrada (interpretação de 
tecla especial) e envia a entrada para um processo lendo do TTY. A saída para um TTY 

é enviada para o código dependente de dispositivo para processamento de saída e exibição 
na "tela". O processamento da entrada é feito pelo dispositivo chamando"in process” 
nos caracteres de entrada; o processamento da saída pode ser feito pelo próprio 
dispositivo ou chamando-se "out process". O TTY trata do enfileiramento da entrada e o 
dispositivo faz o enfileiramento da saída. Se um dispositivo recebe um sinal externo, 
como uma interrupção, então ele faz com que tty wakeup() seja executada pela tarefa CLOCK 
para, você adivinhou, despertar o TTY a fim de verificar se a entrada ou saída pode 
continuar. 


As mensagens válidas e seus parâmetros são: 


* HARD INT: a saída terminou ou a entrada chegou 

o -SYS SIG: ex., o MINIX quer desligar; executa código de parada normal 

* DEV READ: um processo quer ler de um terminal 

* DEV WRITE: um processo quer escrever em um terminal 

* DEV IOCTL: um processo quer alterar os parâmetros de um terminal 

* DEV OPEN: uma Tinha tty line foi aberta 

* DEV CLOSE: uma Tinha tty foi fechada 

* DEV SELECT: inicia o pedido de notificação de seleção 

* DEV STATUS: o FS quer saber o status de SELECT ou REVIVE 

* CANCEL: termina imediatamente uma chamada de sistema incompleta anterior 
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13630 x 

13631 % m_type TTY LINE PROC NR COUNT  TTY SPEK TTY FLAGS ADDRESS 
13632 * --------------------------------------------------------------------------- 
13633 * HARD INT | | 
13634 H p=suscasancsas +--------- +--------- +=======—— &===noncan +--------- +--------- | 
13635 * | SYS SIG sig set | | 
13636 + f=ssssns ass =======—— +======—=— +=======—= d========— +--------- +--------- | 
13637 * | DEV READ minor dev| proc nr count O NONBLOCK| buf ptr | 
13638 E f=cssassuscsas +--------- +======00— === =a-=0= d======na- +222- +--------- | 
13639 * | DEV WRITE minor dev| proc nr count buf ptr | 
13640 + Assn =======—— +======——— +--------- +-------=- +--------- +--------- | 
13641 * | DEV IOCTL minor dev| proc nr |func code|erase etc| flags | 
13642 * |>= +--------- g====n=-an +=====-=—— ===ncnnas +--------- +--------- | 
13643 * DEV OPEN minor dev| proc nr | O NOCTTY | 
13644 + j=sessss=se ses =======—— +=====———— +=======—= d=======0— +========— +--------- | 
13645 * | DEV CLOSE minor dev| proc nr | 
13646 Wo jesasastancess +--------- +-------=- -===a-n=o 4======00— +--------- +--------- | 
13647 % DEV_STATUS | | 
13648 4 | Ssssssesessss +-=====——— +======——— +--------- +=-------- +--------- +--------- | 
13649 * | CANCEL minor dev| proc nr | 
13650 * --------------------------------------------------------------------------- 
13651 R 


13652 * Alterações: 
13653 * 20 de janeiro de 2004 driver de TTY movido para o espaço de usuário (Jorrit N. Herder) 


13654 * 20 de setembro de 2004 gerenciamento temporizador local/alarmes de sinc (J. N. Herder) 
13655 * 13 de julho de 2004 suporte para observadores de tecla de função (Jorrit N. Herder) 
13656 2A 

13657 


13658 #include "../drivers.h" 

13659 #include "../drivers.h" 

13660 #include <termios.h> 

13661 #include <sys/ioc tty.h> 

13662 #include <signal.h> 

13663 &include <minix/callnr.h> 

13664 #include <minix/keymap.h> 

13665 #include "tty.h" 

13666 

13667 #include <sys/time.h> 

13668 #include <sys/select.h> 

13669 

13670 extern int irq_hook_id; 

13671 

13672 unsigned long kbd_irq_set = 0; 

13673 unsigned long rs_irq_set = 0; 

13674 

13675 /* Endereço de uma estrutura tty. */ 
13676 #define tty addr(line) (&tty_table[line]) 
13677 

13678 /* Macros para tipos de tty mágicos. */ 
13679 #define isconsole(tp) CCtp) < tty addr(NR CONS)) 


13680 #define ispty(tp) CCtp) >= tty addr(NR CONS+NR RS LINES)) 

13681 

13682 /* Macros para ponteiros mágicos da estrutura de tty. */ 

13683  &define FIRST TTY tty addr(0) 

13684 ádefine END TTY tty addr(sizeof(tty table) / sizeof(tty table[0])) 
13685 


13686 /* Um dispositivo existe se pelo menos sua função" devread” está definida. */ 
13687 #define tty active(tp) ((tp)->tty devread != NULL) 

13688 

13689 /* linhas RS232 ou pseudo-terminais podem ser completamente configurados. */ 
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13690 
13691 
13692 
13693 
13694 
13695 
13696 
13697 
13698 
13699 
13700 
13701 
13702 
13703 
13704 
13705 
13706 
13707 
13708 
13709 
13710 
13711 
13712 
13713 
13714 
13715 
13716 
13717 
13718 
13719 
13720 
13721 
13722 
13723 
13724 
13725 
13726 
13727 
13728 
13729 
13730 
13731 
13732 
13733 
13734 
13735 
13736 
13737 
13738 
13739 
13740 
13741 
13742 
13743 
13744 
13745 
13746 
13747 
13748 
13749 


Hif NR RS LINES == 
tdefine rs init(tp) 
#endif 

#if NR_PTYS == 
#define pty_init(tp) 


#define do_pty(tp, mp) 


#endif 

FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 


/* Atributos padrão. 


void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 
void 


(Cvoid) 0) 


(Cvoid) 0) 
(Cvoid) 0) 


tty timed out, (timer_t *tp) 

expire timers, (void) 

settimer, (tty t *tty ptr, int enable) 
do cancel, (tty t *tp, message *m ptr) 
do ioctl, (tty t *tp, message *m ptr) 
do open, (tty t *tp, message *m ptr) 
do close, (tty t *tp, message *m ptr) 
do read, (tty t *tp, message *m ptr) 
do write, (tty t *tp, message *m ptr) 
do select, (tty t *tp, message *m ptr) 
do status, (message *m ptr) 

in transfer, (tty t *tp) 


int tty echo, (tty t *tp, int ch) 


void 


rawecho, (tty t *tp, int ch) 


int back over, (tty t *tp) 


void 
void 
void 
void 
void 


*/ 


reprint, (tty_t *tp) 
dev_ioctl, (tty_t *tp) 
setattr, (tty_t *tp) 
tty_icancel, (tty_t *tp) 
tty_init, (void) 


PRIVATE struct termios termios_defaults = { 
TINPUT_DEF, TOUTPUT_DEF, TCTRL_DEF, TLOCAL_DEF, TSPEED_DEF, TSPEED_DEF, 


{ 
TEOF_DEF, TEOL_DEF, TERASE_DEF, TINTR_DEF, TKILL_DEF, TMIN_DEF, 
TQUIT_DEF, TTIME_DEF, TSUSP_DEF, TSTART_DEF, TSTOP_DEF, 
TREPRINT_DEF, TLNEXT_DEF, TDISCARD_DEF, 
E 
3; 
PRIVATE struct winsize winsize defaults; /* = todos zero */ 


/* Variáveis globais para a tarefa TTY (declarada como extern em tty.h). */ 


PUBLIC tty t tty table[NR CONS+NR RS LINES+NR PTYS]; 
/* console correntemente ativo */ 


PUBLIC int ccurrent; 


PUBLIC timer t *tty timers; 


PUBLIC struct machine machine; 


PUBLIC void main(voi 
{ 


d) 


/* Rotina principal da tarefa de terminal. */ 


message tty_mess; 
unsigned line; 
int s3 


/* buffer para todas as mensagens recebidas */ 


mm 


char *types[] = ["task","driver","server", "user"); 
register struct proc *rp; 


register tty t *tp 


/* fila de temporizadores de TTY */ 
PUBLIC clock t tty next timeout; /* tempo em que o próximo alarme é esperado * 
/* variáveis de ambiente do núcleo */ 
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13750 
13751 /* Inicializa o driver TTY. */ 
13752 tty initO; 


13753 

13754 /* Obtém ambiente do núcleo (protected mode, pc at e ega são necessários). */ 
13755 if (OK != (s=sys getmachine(&machine))) { 

13756 panic("TTY","Couldn't obtain kernel environment.", s); 

13757 } 

13758 

13759 /* Última inicialização única do teclado. */ 

13760 kb_init_once(); 

13761 

13762 printfCAn'D; 

13763 

13764 while (TRUE) 1 

13765 

13766 /* Verifica e trata de todos os eventos em qualquer um dos ttys. */ 

13767 for (tp = FIRST TTY; tp < END TTY; tp+) { 

13768 if (tp->tty events) handle events(tp); 

13769 } 

13770 

13771 /* Obtém uma mensagem de requisição. */ 

13772 receive(ANY, &tty_mess); 

13773 

13774 /* Primeiro manipula todos os tipos de notificação do núcleo suportados pelo TTY. 
13775 * — Um alarme foi disparado, expira todos os temporizadores e trata dos eventos. 
13776 * — Uma interrupção de hardware também é um convite para verificar eventos. 
13777 * — Uma nova mensagem do núcleo está disponível para impressão. 

13778 * — Reconfigura o console no desligamento do sistema. Então, vê 

13779 z se essa mensagem é diferente de uma requisição de driver de dispositivo 
13780 * normal e se deve ser manipulada separadamente. Essas funções extras 

13781 * não operam em um dispositivo, em constraste com as requisições de driver. 
13782 */ 

13783 switch (tty mess.m type) É 

13784 case SYN ALARM: /* falha */ 

13785 expire timersQO; /* chama cães de guarda de temporizadores expirados */ 
13786 continue; /* continua a verificar eventos */ 

13787 case HARD INT: 1 /* notificação de interrupção de hardware */ 
13788 if (tty mess.NOTIFY ARG & kbd irq set) 

13789 kbd interrupt(&tty mess);/* busca caracteres do teclado */ 
13790 #if NRRS LINES > O 

13791 if (tty mess.NOTIFY ARG & rs irq set) 

13792 rs interrupt(&tty mess);/* E/S serial */ 

13793 #endif 

13794 expire timersQO; /* chama cães de guarda de temporizadores expirados */ 
13795 continue; /* continua a verificar eventos */ 

13796 } 

13797 case SYS_SIG: { /* sinal do sistema */ 

13798 sigset_t sigset = (sigset_t) tty_mess.NOTIFY_ARG; 

13799 

13800 if (sigismember(&sigset, SIGKSTOP)) { 

13801 cons stop(); /* troca para o console principal */ 
13802 if Cirq hook id != -1) 1 

13803 sys irqdisable(&irgq hook id); 

13804 sys irgqrmpolicy(KEYBOARD IRQ, &irq hook id); 

13805 } 

13806 } 

13807 if (sigismember(&sigset, SIGTERM)) cons stop; 

13808 if (sigismember(&sigset, SIGKMESS)) do new kmess(&tty mess); 


13809 continue; 
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13810 
13811 
13812 
13813 
13814 
13815 
13816 
13817 
13818 
13819 
13820 
13821 
13822 
13823 
13824 
13825 
13826 
13827 
13828 
13829 
13830 
13831 
13832 
13833 
13834 
13835 
13836 
13837 
13838 
13839 
13840 
13841 
13842 
13843 
13844 
13845 
13846 
13847 
13848 
13849 
13850 
13851 
13852 
13853 
13854 
13855 
13856 
13857 
13858 
13859 
13860 
13861 
13862 
13863 
13864 
13865 
13866 
13867 
13868 
13869 


} 

case PANIC_DUMPS: /* permite dumps de pânico */ 
cons_stop(); /* troca para o console principal */ 
do panic dumps(&tty mess); 
continue; 

case DIAGNOSTICS: /* um servidor quer imprimir algo */ 
do diagnostics(&tty mess); 
continue; 

case FKEY CONTROL: /* Cun)register a fkey observer */ 
do fkey ctI(&tty mess); 
continue; 

default: /* deve ser uma requisição de driver */ 
: /* não faz nada; fim do switch */ 

} 


/* Apenas requisições de dispositivo devem chegar até este ponto. Todas as 
* requisições, exceto DEV_STATUS, têm um nr. do dispositivo secundário. 


* Verifica essa exceção e obtém o nr. do dispositivo secundário, caso contrário. 


*/ 
if (tty_mess.m_type == DEV STATUS) { 
do status(&tty mess); 
continue; 
} 
line = tty_mess.TTY_LINE; 
if (Cline - CONS MINOR) < NR CONS) { 
tp = tty addr(line - CONS MINOR); 
+ else if (line == LOG MINOR) { 
tp = tty addr(0); 
} else if (Cline - RS232 MINOR) < NR RS LINES) { 
tp = tty addr(line - RS232 MINOR + NR CONS); 
} else if ((Cline - TTYPX MINOR) < NR PTYS) { 
tp = tty addr(line - TTYPX MINOR + NR CONS + NR RS LINES); 
} else if (Cline - PTYPX MINOR) < NR PTYS) { 
tp = tty addr(line - PTYPX MINOR + NR CONS + NR RS LINES); 
if (tty mess.m type != DEV IOCTL) 1 
do pty(tp, &tty mess); 
continue; 
} 
} else { 
tp = NULL; 
} 


/* Se o dispositivo não existe ou não está configurado, retorna ENXIO. 


if (tp == NULL || ! tty_active(tp)) { 
printf("Warning, TTY got illegal request %d from %d\n", 
tty_mess.m_type, tty_mess.m_source); 
tty_reply(TASK_REPLY, tty_mess.m_source, 
tty_mess.PROC_NR, ENXIO); 
continue; 


} 


/* Executa a função de driver de dispositivo solicitada. */ 
switch (tty_mess.m_type) { 


case DEV_READ: do_read(tp, &tty_mess); break; 
case DEV_WRITE: do_write(tp, &tty_mess); break; 
case DEV_IOCTL: do_ioctl(tp, &tty_mess); break; 
case DEV_OPEN: do open(tp, &tty mess); break; 
case DEV CLOSE: do close(tp, &tty mess); break; 
case DEV SELECT: do select(tp, &tty mess); break; 


case CANCEL: do cancel(tp, &tty mess); break; 


sy 
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13870 default: 

13871 printfC"warning, TTY got unexpected request %d from %d\n", 
13872 tty mess.m type, tty mess.m source); 

13873 tty reply(TASK REPLY, tty mess.m source, 

13874 tty mess.PROC NR, EINVAL); 


13882 PRIVATE void do status(m ptr) 
13883 message *m ptr; 


13884 { 

13885 register struct tty *tp; 

13886 int event found; 

13887 int status; 

13888 int ops; 

13889 

13890 /* Verifica eventos de seleção ou reanimação em qualquer um dos ttys. Se encontrarmos um 
13891 * evento, retorna uma única mensagem de status para ele. O FS fará outra 

13892 * chamada para ver se existem mais. 

13893 */ 


13894 event_found = 0; 
13895 for (tp = FIRST_TTY; tp < END_TTY; tp++) { 


13896 if (Cops = select_try(tp, tp->tty_select_ops)) && 

13897 tp->tty_select_proc == m_ptr->m_source) { 

13898 

13899 /* E/S para um dispositivo secundário selecionado que está pronto. */ 
13900 m_ptr->m_type = DEV_IO_READY; 

13901 m_ptr->DEV_MINOR = tp->tty_index; 

13902 m_ptr->DEV_SEL_OPS = ops; 

13903 

13904 tp->tty_select_ops &= “ops; /* desmarca o evento de seleção */ 
13905 event_found = 1; 

13906 break; 

13907 

13908 else if (tp->tty_inrevived && tp->tty_incaller == m_ptr->m_source) { 
13909 

13910 /* Requisição suspensa concluída. Envia REVIVE. */ 

13911 m_ptr->m_type = DEV_REVIVE; 

13912 m_ptr->REP_PROC_NR = tp->tty_inproc; 

13913 m_ptr->REP_STATUS = tp->tty_incum; 

13914 

13915 tp->tty_inleft = tp->tty_incum = 0; 

13916 tp->tty_inrevived = 0; /* desmarca o evento de reanimação */ 
13917 event found = 1; 

13918 break; 

13919 

13920 else if (tp->tty outrevived && tp->tty outcaller == m ptr->m source) { 
13921 

13922 /* Requisição suspensa concluída. Envia REVIVE. */ 

13923 m ptr->m type = DEV REVIVE; 

13924 m ptr->REP PROC NR = tp->tty outproc; 

13925 m ptr->REP STATUS = tp->tty outcum; 

13926 

13927 tp->tty outcum = 0; 

13928 tp->tty outrevived = 0; /* desmarca o evento de reanimação */ 


13929 event found = 1; 
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13930 
13931 
13932 
13933 
13934 
13935 
13936 
13937 
13938 
13939 
13940 
13941 
13942 
13943 
13944 
13945 
13946 
13947 
13948 


13950 
13951 
13952 
13953 
13954 
13955 
13956 
13957 
13958 
13959 
13960 
13961 
13962 
13963 
13964 
13965 
13966 
13967 
13968 
13969 
13970 
13971 
13972 
13973 
13974 
13975 
13976 
13977 
13978 
13979 
13980 
13981 
13982 
13983 
13984 
13985 
13986 
13987 
13988 
13989 


break; 


} 


#if NR_PTYS > 0 
if (levent found) 
event found = pty status(m ptr); 
#endif 


if (! event found) { 
/* Nenhum evento de interesse foi encontrado. Retorna uma mensagem vazia. */ 
m ptr->m type = DEV NO STATUS; 

} 


/* Quase pronto. Envia mensagem de resposta para o processo que fez a chamada. */ 
if ((status = send(m_ptr->m_source, m_ptr)) != OK) { 
panic("TTY", "send in do status failed, status\n", status); 


PRIVATE void do_read(tp, m_ptr) 


register tty_t *tp; /* ponteiro para estrutura tty */ 
register message *m_ptr; /* ponteiro para mensagem enviada para a tarefa */ 
{ 


/* Um processo quer ler de um terminal. */ 
int r, status; 
phys bytes phys addr; 


/* Verifica se já existe um processo suspenso em uma leitura, verifica se os 
* parâmetros estão corretos, executa a E/S. 


*/ 

if (tp->tty_inleft > 0) { 
r = EIO; 

} else 

if (m_ptr->COUNT <= 0) { 
r = EINVAL; 

} else 


if (sys umap(m ptr->PROC NR, D, (vir bytes) m_ptr->ADDRESS, m ptr->COUNT, 
&phys addr) != 0K) 1 
r = EFAULT; 
} else { 
/* Copia informações da mensagem na estrutura tty. */ 
tp->tty_inrepcode = TASK_REPLY; 
tp->tty incaller = m_ptr->m_source; 
tp->tty_inproc = m_ptr->PROC_NR; 
tp->tty_in_vir = (vir_bytes) m_ptr->ADDRESS; 
tp->tty_inleft = m ptr->COUNT; 


if (!(tp->tty_termios.c_lflag & ICANON) 
&& tp->tty_termios.c_cc[VTIME] > 0) { 
if (tp->tty termios.c cc[VMIN] == 0) { 
/* MIN & TIME especificam um temporizador que termina a leitura 
* em TIME/10 segundos, caso nenhum byte esteja disponível. 
a, 
settimer(tp, TRUE); 
tp->tty min = 1; 
} else { 
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13990 
13991 
13992 
13993 
13994 
13995 
13996 
13997 
13998 
13999 
14000 
14001 
14002 
14003 
14004 
14005 
14006 
14007 
14008 
14009 
14010 
14011 
14012 
14013 
14014 
14015 
14016 
14017 
14018 
14019 
14020 
14021 
14022 
14023 
14024 


14026 
14027 
14028 
14029 
14030 
14031 
14032 
14033 
14034 
14035 
14036 
14037 
14038 
14039 
14040 
14041 
14042 
14043 
14044 
14045 
14046 
14047 
14048 
14049 


/* MIN & TIME especificam um temporizador entre bytes que talvez 


tenha de ser cancelado, caso ainda não existam bytes. 
*/ 

if (tp->tty eotct == 0) 1 

settimer(tp, FALSE); 

tp->tty min = tp->tty termios.c cc[VMIN]; 


} 
} 
} 
/* Algo está esperando no buffer de entrada? Limpa... */ 
in transfer(tp); 
/* ... então, volta para obter mais. */ 


handle events(tp); 
if Ctp->tty inleft == 0) 1 
if (tp->tty select ops) 
select retry(tp); 
return; /* pronto */ 


} 


/* Não havia bytes disponíveis na fila de entrada; portanto, ou suspende 


*/ 
if (m_ptr->TTY_FLAGS & O NONBLOCK) { 
r = EAGAIN; /* cancela a leitura */ 
tp->tty_inleft = tp->tty_incum = 0; 
} else { 
r = SUSPEND; /* suspende o processo que fez a chamada */ 
tp->tty_inrepcode = REVIVE; 
} 


} 
tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, r); 
if (tp->tty_select_ops) 

select_retry(tp); 


} 
Ji En 
* do write * 
CODDDSSSSSSSSDSSSSSS==D=D=================================================== * / 
PRIVATE void do write(tp, m ptr) 
register tty t *tp; 
register message *m ptr; /* ponteiro para mensagem enviada para a tarefa */ 
{ 
/* Um processo quer escrever em um terminal. */ 


int r; 
phys bytes phys addr; 


/* Verifica se já existe um processo suspenso em uma escrita, verifica se os 
* parâmetros estão corretos, realiza a E/S. 
*/ 
if (tp->tty_outleft > 0) { 
r = EIO; 
+ else 
if (m ptr->COUNT <= 0) 1 
r = EINVAL; 
+ else 
if (sys umap(m ptr->PROC NR, D, (vir bytes) m ptr->ADDRESS, m ptr->COUNT, 
&phys addr) != OK) 1 
r = EFAULT; 
} else { 


o processo que fez a chamada ou interrompe a leitura, se for não bloqueante. 
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14050 /* Copia parâmetros da mensagem na estrutura tty. */ 

14051 tp->tty outrepcode = TASK REPLY; 

14052 tp->tty outcaller = m ptr->m source; 

14053 tp->tty outproc = m ptr->PROC NR; 

14054 tp->tty out vir = (vir bytes) m ptr->ADDRESS; 

14055 tp->tty outleft = m ptr->COUNT; 

14056 

14057 /* Tenta escrever. */ 

14058 handle events(tp); 

14059 if (tp->tty outleft == 0) 

14060 return; /* pronto */ 

14061 

14062 /* Nenhum ou nem todos os bytes puderam ser escritos; portanto, ou suspende o 
14063 * processo que fez a chamada ou interrompe a escrita se for não bloqueante. 
14064 E 

14065 if Cm ptr->TTY FLAGS & O NONBLOCK) 1 /* cancela a escrita */ 

14066 r = tp->tty outcum > 0 ? tp->tty outcum : EAGAIN; 

14067 tp->tty outleft = tp->tty outcum = 0; 

14068 } else { 

14069 r = SUSPEND; /* suspende o processo que fez a chamada */ 
14070 tp->tty_outrepcode = REVIVE; 

14071 } 

14072 } 

14073 tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, r); 

14074 } 


14078 ¥ D= ¥ / 
14079 PRIVATE void do_ioctl(tp, m ptr) 
14080 register tty_t *tp; 


14081 message *m_ptr; /* ponteiro para mensagem enviada para a tarefa */ 
14082 { 

14083 /* Executa uma operação IOCTL nesse terminal. As chamadas de termios do Posix são 
14084 * manipuladas pela chamada de sistema IOCTL 

14085 */ 

14086 


14087 int r? 
14088 union { 


14089 int i; 

14090 } param; 

14091 size_t size; 

14092 

14093 /* Tamanho do parâmetro ioctl. */ 

14094 switch (m_ptr->TTY_REQUEST) { 

14095 case TCGETS: /* função tcgetattr do Posix */ 

14096 case TCSETS: /* função tcsetattr do Posix, opção TCSANOW */ 
14097 case TCSETSW: /* função tcsetattr do Posix, opção TCSADRAIN */ 
14098 case TCSETSF: /* função tcsetattr do Posix, opção TCSAFLUSH */ 
14099 size = sizeof(struct termios); 

14100 break; 

14101 

14102 case TCSBRK: /* função tcsendbreak do Posix */ 

14103 case TCFLOW: /* função tcflow do Posix */ 

14104 case TCFLSH: /* função tcflush do Posix */ 

14105 case TIOCGPGRP: /* função tcgetpgrp do Posix */ 

14106 case TIOCSPGRP: /* função tcsetpgrp do Posix */ 

14107 size = sizeof(int); 

14108 break; 
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14110 
14111 
14112 
14113 
14114 
14115 
14116 
14117 
14118 
14119 
14120 
14121 
14122 
14123 
14124 
14125 
14126 
14127 
14128 
14129 
14130 
14131 
14132 
14133 
14134 
14135 
14136 
14137 
14138 
14139 
14140 
14141 
14142 
14143 
14144 
14145 
14146 
14147 
14148 
14149 
14150 
14151 
14152 
14153 
14154 
14155 
14156 
14157 
14158 
14159 
14160 
14161 
14162 
14163 
14164 
14165 
14166 
14167 
14168 
14169 


case TIOCGWINSZ: /* obtém tamanho da janela (não é do Posix) */ 
case TIOCSWINSZ: /* configura tamanho da janela (não é do Posix) */ 
size = sizeof(struct winsize); 
break; 
case KIOCSMAP: /* carrega mapa de teclas (extensão do Minix) */ 
size = sizeof(keymap t); 
break; 
case TIOCSFON: /* carrega fonte (extensão do Minix) */ 
size = sizeof(u8 t [8192]); 
break; 
case TCDRAIN: /* função tcdrain do Posix - sem parâmetro */ 
default: size = 0; 
} 
r= 0; 


switch (m ptr->TTY REQUEST) { 
case TCGETS: 
/* Obtém os atributos de termios. */ 
r = sys vircopy(SELF, D, (vir bytes) &tp->tty termios, 
m ptr->PROC NR, D, (vir bytes) m ptr->ADDRESS, 
(vir bytes) size); 
break; 


case TCSETSW: 
case TCSETSF: 
case TCDRAIN: 
if (tp->tty outleft > 0) 1 


/* Espera por todo processamento de saída em andamento para terminar. 


tp->tty iocaller = m ptr->m source; 
tp->tty ioproc = m ptr->PROC NR; 
tp->tty ioreq = m ptr->REQUEST; 
tp->tty iovir = (vir bytes) m ptr->ADDRESS; 
r = SUSPEND; 
break; 
} 
if (m_ptr->TTY_REQUEST == TCDRAIN) break; 
if (m_ptr->TTY_REQUEST == TCSETSF) tty_icancel(tp); 
/*FALL THROUGH*/ 
case TCSETS: 
/* Configura os atributos de termios. */ 
r = sys_vircopy( m_ptr->PROC_NR, D, (vir bytes) m ptr->ADDRESS, 
SELF, D, (vir_bytes) &tp->tty_termios, (vir_bytes) size); 
if (r != OK) break; 
setattr(tp); 
break; 


case TCFLSH: 
r = sys vircopy(m ptr->PROC NR, D, (vir bytes) m ptr->ADDRESS, 
SELF, D, (vir bytes) &param.i, (vir bytes) size); 
if (r != OK) break; 
switch (param.i) 1 


case TCIFLUSH: tty icancel (tp); break; 
case TCOFLUSH: (*tp->tty ocancel) (tp, 0); break; 
case TCIOFLUSH: tty icancel (tp); (*tp->tty ocancel) (tp, 0); break; 
default: r = EINVAL; 

F 

break; 


27 
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14170 
14171 
14172 
14173 
14174 
14175 
14176 
14177 
14178 
14179 
14180 
14181 
14182 
14183 
14184 
14185 
14186 
14187 
14188 
14189 
14190 
14191 
14192 
14193 
14194 
14195 
14196 
14197 
14198 
14199 
14200 
14201 
14202 
14203 
14204 
14205 
14206 
14207 
14208 
14209 
14210 
14211 
14212 
14213 
14214 
14215 
14216 
14217 
14218 
14219 
14220 
14221 
14222 
14223 
14224 
14225 
14226 
14227 
14228 
14229 


case TCFLOW: 
r = sys vircopy(m ptr->PROC NR, D, (vir bytes) m ptr->ADDRESS, 
SELF, D, (vir bytes) &param.i, (vir bytes) size); 
if Cr != OK) break; 
switch (param.i) 1 
case TCOOFF: 
case TCOON: 
tp->tty inhibited = (param.i == TCOOFF); 
tp->tty events = 1; 
break; 
case TCIOFF: 
(“tp->tty echo) (tp, tp->tty termios.c cc[VSTOP]); 


break; 
case TCION: 
(*tp->tty echo) (tp, tp->tty termios.c cc[VSTART]); 
break; 
default: 
r = EINVAL; 
} 
break; 


case TCSBRK: 
if (tp->tty_break != NULL) (*tp->tty break) (tp,0); 
break; 


case TIOCGWINSZ: 
r = sys_vircopy(SELF, D, (vir_bytes) &tp->tty_winsize, 
m_ptr->PROC_NR, D, (vir_bytes) m_ptr->ADDRESS, 
(vir bytes) size); 
break; 


case TIOCSWINSZ: 
r = sys vircopy(m ptr->PROC NR, D, (vir bytes) m ptr->ADDRESS, 
SELF, D, (vir bytes) &tp->tty winsize, (vir bytes) size); 
/* SIGWINCH... */ 
break; 


case KIOCSMAP: 
/* Carrega um novo mapa de teclas (somente /dev/console). */ 
if (isconsole(tp)) r = kbd Toadmap(m ptr); 
break; 


case TIOCSFON: 
/* Carrega uma font em uma placa EGA ou VGA (hsQhck.hr) */ 
if (isconsole(tp)) r = con Toadfont(m ptr); 
break; 


/* Essas funções do Posix podem falhar se | POSIX JOB CONTROL não 

* estiver definida. 
*/ 

case TIOCGPGRP: 

case TIOCSPGRP: 

default: 

r = ENOTTY; 

} 


/* Envia a resposta. */ 
tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, r); 
} 
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14231 
14232 
14233 
14234 PRIVATE void do open(tp, m ptr) 

14235 register tty t *tp; 

14236 message “m ptr; /* ponteiro para message enviada para a tarefa */ 

14237 | 

14238 /* Uma linha de tty foi aberta. Faz os procedimentos que fizeram a chamada controlar o tty 
14239 * se O NOCTTY *não* estiver configurado e não for o dispositivo de log. 1 é retornado se 
14240 * o tty tornou-se o tty de controle, caso contrário, OK ou um código de erro. 

14241 */ 

14242 int r = OK; 

14243 

14244 if (m_ptr->TTY_LINE == LOG_MINOR) { 

14245 /* O dispositivo de log é um dispositivo de diagnóstico somente para escrita. */ 

14246 if (m_ptr->COUNT & R_BIT) r = EACCES; 

14247 } else { 

14248 if C! Cm ptr->COUNT & O_NOCTTY)) { 

14249 tp->tty_pgrp = m_ptr->PROC_NR; 

14250 ræ 

14251 } 

14252 tp->tty_openct++; 

14253 } 

14254 tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, r); 

14255 } 


i4257 J" a A 
14258 * do close * 
14259 EDDS====D=D>=>>=>>=>>=>>>=>>=>>=>>>>>>>=>>=>>=>>>>>>=>>=>>=>>>>>>>>=>>=>>=>=>>>=>=>===>===> * / 
14260 PRIVATE void do close(tp, m ptr) 

14261 register tty t *tp; 

14262 message “m ptr; /* ponteiro para a mensagem enviada para a tarefa */ 
14263 1 

14264 /* Uma Tinha de tty foi fechada. Limpa a linha, se é o último fechamento. */ 

14265 

14266 if Cm ptr->TTY LINE != LOG MINOR && --tp->tty openct == 0) { 


14267 tp->tty pgrp = 0; 

14268 tty icancel (tp); 

14269 (*tp->tty ocancel) (tp, 0); 

14270 (C*tp->tty close) (tp, 0); 

14271 tp->tty termios = termios defaults; 

14272 tp->tty winsize = winsize defaults; 

14273 setattr(tp); 

14274 

14275 tty replyCTASK REPLY, m ptr->m source, m ptr->PROC NR, OK); 

14276 3 

14278 f aa 
14279 ; do cancel * 
14280 FEEDS ESSES SD ECCICS-=SSSDSCD SEE st 


14281 PRIVATE void do cancel(tp, m ptr) 
14282 register tty t *tp; 


14283 message “m ptr; /* ponteiro para a mensagem enviada para a tarefa */ 
14284 1 

14285 /* Um sinal foi enviado para um processo que está travado tentando ler ou escrever. 
14286 * A leitura ou escrever pendente deve ser concluída imediatamente. 

14287 */ 

14288 


14289 int proc nr; 
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14290 
14291 
14292 
14293 
14294 
14295 
14296 
14297 
14298 
14299 
14300 
14301 
14302 
14303 
14304 
14305 
14306 
14307 
14308 
14309 
14310 
14311 


14313 
14314 
14315 
14316 
14317 
14318 
14319 
14320 
14321 
14322 
14323 
14324 
14325 
14326 
14327 
14328 
14329 
14330 
14331 
14332 
14333 
14334 
14335 
14336 
14337 
14338 
14339 
14340 
14341 
14342 
14343 
14344 
14345 
14346 


14348 
14349 


int mode; 


/* Verifica os parâmetros cuidadosamente para evitar cancelamento duplo. */ 

proc nr = m ptr->PROC NR; 

mode = m ptr->COUNT; 

if ((mode & R BIT) && tp->tty inleft != 0 && proc nr == tp->tty inproc) { 
/* O processo estava lendo quando foi eliminado. Limpa a entrada. */ 
tty icancel (tp); 
tp->tty inleft = tp->tty incum = 0; 


} 

if ((mode & W_BIT) && tp->tty_outleft != 0 && proc nr == tp->tty_outproc) { 
/* O processo estava escrevendo quando foi eliminado. Limpa a saída. */ 
(“tp->tty ocancel) (tp, 0); 
tp->tty outleft = tp->tty outcum = 0; 

} 

if (tp->tty_ioreq != 0 && proc nr == tp->tty ioproc) { 
/* O processo estava esperando a saída terminar. */ 
tp->tty ioreg = 0; 

} 

tp->tty_events = 1; 

tty_reply(TASK_REPLY, m_ptr->m_source, proc_nr, EINTR); 


} 
PUBLIC int select_try(struct tty *tp, int ops) 
{ 
int ready_ops = 0; 
/* Caso especial. Se a linha foi desligada, nenhuma operaççao bloqueará. 
* (e isso pode ser visto como uma condição excepcional.) 
*/ 
if (tp->tty_termios.c_ospeed == B0) { 
ready_ops |= ops; 
} 
if Cops & SEL RD) { 
/* a e/s não bloqueará na leitura? */ 
if Ctp->tty inleft > 0) { 
ready_ops |= SEL_RD; /* EIO - não bloqueante */ 
} else if (tp->tty_incount > 0) { 
/* Uma leitura normal é possível? tty_incount 
* diz que há dados. Mas uma leitura só terá êxito 
* no modo canônico se um caractere de nova linha foi visto. 
*/ 
if (!(tp->tty_termios.c_lflag & ICANON) || 
tp->tty_eotct > 0) { 
ready_ops |= SEL_RD; 
} 
} 
} 
if (Cops & SEL_WR) { 
if (tp->tty_outleft > 0) ready ops |= SEL_WR; 
else if ((*tp->tty_devwrite)(tp, 1)) ready_ops |= SEL_WR; 
} 
return ready ops; 
} 


PUBLIC int select_retry(struct tty *tp) 
{ 
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14350 if (select try(tp, tp->tty select ops)) 

14351 notify(tp->tty select proc); 

14352 return OK; 

14353 } 

14355 === 

14356 i handle_events ii 
14357  *========================== À ) 
14358 PUBLIC void handle events(tp) 

14359 tty t *tp; /* TTY para verificar eventos. */ 

14360 { 

14361 /* Trata de todos os eventos pendentes em um TTY. Esses eventos normalmente são 
14362 * interrupções de dispositivo. 

14363 * 

14364 * Dois tipos de eventos são importantes: 

14365 x - um caractere foi recebido do console ou de uma linha RS232. 

14366 * - uma linha RS232 concluiu uma requisição de escrita (em nome de um usuário). 
14367 * A rotina de tratamento de interrupção pode atrasar a mensagem de interrupção à vontade 
14368 * para não atolar a tarefa TTY. Mensagens podem ser sobrescritas quando as 
14369 * linhas são rápidas ou quando há disputas entre diferentes linhas, entrada 
14370 * e saída, pois o MINIX só fornece buffer do tipo simples para mensagens de 
14371 * interrupção (em proc.c). Isso é tratado verificando-se explicitamente cada linha 
14372 * quanto uma nova entrada e saída concluída em cada interrupção. 

14373 */ 

14374 char *buf; 

14375 unsigned count; 

14376 int status; 

14377 

14378 do { 

14379 tp->tty_events = 0; 

14380 

14381 /* Lê a entrada e realiza o processamento de entrada. */ 

14382 (“tp->tty devread) (tp, 0); 

14383 

14384 /* Realiza o processamento de saída e escreve a saída. */ 

14385 (*tp->tty devwrite) (tp, 0); 

14386 

14387 /* Ioctl esperando por algum evento? */ 

14388 if (tp->tty ioreq != 0) dev ioctl(tp); 

14389 } while (tp->tty events); 

14390 

14391 /* Transfere caracteres da fila de entrada para um processo que está esperando. */ 
14392 in transfer(tp); 

14393 

14394 /* Responde se houver bytes suficientes disponíveis. */ 

14395 if (tp->tty incum >= tp->tty min && tp->tty inleft > 0) { 

14396 if (tp->tty inrepcode == REVIVE) { 

14397 notify(tp->tty incaller); 

14398 tp->tty inrevived = 1; 

14399 } else { 

14400 tty_reply(tp->tty_inrepcode, tp->tty_incaller, 

14401 tp->tty_inproc, tp->tty incum); 

14402 tp->tty inleft = tp->tty incum = 0; 

14403 

14404 } 

14405 if (tp->tty select ops) 

14406 select retry(tp); 


14407 #if NR PTYS > 0 
14408 if CisptyCtp)) 
14409 select retry pty(tp); 
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14410 
14411 
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14427 
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14435 
14436 
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14448 
14449 
14450 
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14452 
14453 
14454 
14455 
14456 
14457 
14458 
14459 
14460 
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14462 
14463 
14464 
14465 
14466 
14467 
14468 
14469 


PRIVATE void in transfer(tp) 


register tty t *tp; 


{ 


/* ponteiro para terminal a ser lido */ 


/* Transfere bytes da fila de entrada para um processo que esteja lendo de um terminal. */ 


int ch; 
int count; 
char buf[64], *bp; 


/* Obriga a leitura a ter êxito se a linha foi desligada, parece EOF para o leitor. */ 
if (tp->tty termios.c ospeed == BO) tp->tty min = 0; 


/* Algo a fazer? */ 
if Ctp->tty inleft == 0 || tp->tty eotct < tp->tty min) return; 


bp = buf; 
while (tp->tty inleft > 0 && tp->tty eotct > 0) É 


} 


ch = *tp->tty intail; 


if (1(ch & IN EOF)) { 
/* Um caractere a ser enviado para o usuário. */ 
*bp = ch & IN CHAR; 
tp->tty inleft--; 
if (++bp == bufend(buf)) 1 
/* Buffer temp cheio, copia no espaço de usuário. */ 
sys vircopy(SELF, D, (vir bytes) buf, 
tp->tty inproc, D, tp->tty in vir, 
(vir bytes) buflenCbuf)); 
tp->tty in vir += buflenCbuf); 
tp->tty incum += buflenCbuf); 
bp = buf; 


} 


/* Remove o caractere da fila de entrada. */ 
if (4+tp->tty intail == bufend(tp->tty_inbuf)) 
tp->tty_intail = tp->tty_inbuf; 
tp->tty_incount--; 
if (ch & IN_EOT) { 
tp->tty_eotct--; 
/* Não Tê após uma quebra de linha no modo canônico. */ 
if (tp->tty termios.c 1lflag & ICANON) tp->tty inleft = 0; 


if (bp > buf) { 


/* Caracteres restantes no buffer. */ 
count = bp - buf; 
sys vircopy(SELF, D, (vir bytes) buf, 
tp->tty inproc, D, tp->tty in vir, (vir bytes) count); 
tp->tty in vir += count; 
tp->tty incum += count; 
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14471 
14472 
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14479 
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14483 
14484 
14485 
14486 
14487 
14488 
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14499 
14500 
14501 
14502 
14503 
14504 
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14526 
14527 
14528 
14529 


/* Normalmente, responde para o leitor, possivelmente mesmo se incum == 0 (EOF). 


if (tp->tty_inleft == 0) { 

if (tp->tty_inrepcode == REVIVE) { 
notify(tp->tty incaller); 
tp->tty inrevived = 1; 

} else { 
tty_reply(tp->tty_inrepcode, tp->tty_incaller, 

tp->tty_inproc, tp->tty_incum); 

tp->tty_inleft = tp->tty_incum = 0; 


PUBLIC int in_process(tp, buf, count) 


register tty_t *tp; /* terminal no qual o caractere chegou */ 
char *buf; /* buffer com caracteres de entrada */ 
int count; /* número de caracteres de entrada */ 

{ 


/* Os caracteres acabaram de ser digitados. Processa, salva e os ecoa. Retorna 
* o número de caracteres processados. 


a 


int ch, sig, ct; 
int timeset = FALSE; 
static unsigned char csize mask[] = { 0x1F, 0x3F, Ox7F, OxFF 3; 


for (ct = 0; ct < count; ct++) { 
/* Pega um caractere. */ 
ch = *buf++ & BYTE; 


/* Retira sete bits? */ 
if (tp->tty termios.c iflag & ISTRIP) ch & 0x7F; 


/* Extensões de entrada? */ 
if (tp->tty termios.c Iflag & IEXTEN) 1 


/* O caractere anterior era um escape de caractere? */ 
if (tp->tty escaped) 1 

tp->tty escaped = NOT ESCAPED; 

ch |= IN ESC; /* caractere protegido */ 
} 


/* LNEXT (CV) para fazer o escape do próximo caractere? */ 
if (ch == tp->tty termios.c cc[VLNEXTIT) { 
tp->tty escaped = ESCAPED; 


rawecho(tp, °™’); 
rawecho(tp, 'Nb'D; 
continue; /* não armazena o escape */ 


} 


/* REPRINT (CR) para reimprimir caracteres ecoados? */ 
if (ch == tp->tty termios.c cc[VREPRINTI) 1 
reprint(tp); 
continue; 


*/ 
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14530 /* -POSIX VDISABLE é um valor de caractere normal, é melhor que tenha escape. */ 
14531 if (ch == POSIX VDISABLE) ch |= IN ESC; 

14532 

14533 /* Faz o mapeamento de CR em LF, ignora CR ou faz o mapeamento de LF em CR. */ 
14534 if (ch == Ar') E 

14535 if (tp->tty termios.c iflag & IGNCR) continue; 

14536 if (tp->tty termios.c iflag & ICRNL) ch = "An"; 

14537 } else 

14538 if (ch == Nn) T 

14539 if (tp->tty termios.c iflag & INLCR) ch = Nr”; 

14540 

14541 

14542 /* Modo canônico? */ 

14543 if (tp->tty termios.c 1flag & ICANON) 1 

14544 

14545 /* Processamento de apagamento (apaga o último caractere). */ 
14546 if (ch == tp->tty termios.c cc[VERASEI) { 

14547 (void) back over(tp); 

14548 if (1(tp->tty termios.c Tflag & ECHOE)) { 

14549 (void) tty echo(tp, ch); 

14550 } 

14551 continue; 

14552 } 

14553 

14554 /* Processamento de eliminação (remove a linha corrente). */ 
14555 if (ch == tp->tty_termios.c_cc[VKILL]) { 

14556 while (back_over(tp)) {} 

14557 if (1(tp->tty termios.c Tflag & ECHOE)) { 

14558 (void) tty echo(tp, ch); 

14559 if (tp->tty termios.c Iflag & ECHOK) 

14560 rawecho(tp, ’°\n’); 

14561 } 

14562 continue; 

14563 } 

14564 

14565 /* EOF (°D) significa fim de arquivo, uma "quebra de linha" invisível. */ 
14566 if (ch == tp->tty termios.c cc[VEOF]) ch |= IN_EOT | IN EOF; 
14567 

14568 /* A linha pode ser retornada para o usuário após um LF. */ 
14569 if (ch == ’\n?’) ch |= IN EOT; 

14570 

14571 /* A mesma coisa com EOL, o que quer que possa ser. */ 

14572 if (ch == tp->tty termios.c cc[VEOL]) ch |= IN EOT; 

14573 } 

14574 

14575 /* Inicia/pára controle de entrada? */ 

14576 if (tp->tty termios.c iflag & IXON) { 

14577 

14578 /* A saída pára em STOP (CS). */ 

14579 if (ch == tp->tty termios.c cc[VSTOP]) { 

14580 tp->tty inhibited = STOPPED; 

14581 tp->tty events = 1; 

14582 continue; 

14583 } 

14584 

14585 /* A saída recomeça em START ("Q) ou qualquer caractere, se IXANY. */ 
14586 if Ctp->tty inhibited) { 

14587 if (ch == tp->tty termios.c cc[VSTART] 

14588 || Ctp->tty termios.c iflag & IXANY)) { 


14589 tp->tty inhibited = RUNNING; 
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14590 tp->tty events = 1; 

14591 if (ch == tp->tty termios.c cc[VSTART]) 
14592 continue; 

14593 } 

14594 } 

14595 } 

14596 

14597 if (tp->tty_termios.c_lflag & ISIG) { 

14598 /* Verifica caracteres INTR (°?) e QUIT (ND). */ 

14599 if (ch == tp->tty termios.c cc[VINTR] 

14600 || ch == tp->tty termios.c cc[VQUITI) { 
14601 sig = SIGINT; 

14602 if (ch == tp->tty termios.c cc[VQUIT]) sig = SIGQUIT; 
14603 sigchar(tp, sig); 

14604 (void) tty echo(tp, ch); 

14605 continue; 

14606 

14607 

14608 

14609 /* Há espaço no buffer de entrada? */ 

14610 if (tp->tty incount == buflenCtp->tty inbuf)) { 

14611 /* Não há espaço; descarta no modo canônico, mantém no modo bruto. */ 
14612 if (tp->tty termios.c 1flag & ICANON) continue; 

14613 break; 

14614 } 

14615 

14616 if (!(tp->tty_termios.c_lflag & ICANON)) { 

14617 /* No modo bruto, todos os caracteres são "quebras de linha". */ 
14618 ch |= IN EOT; 

14619 

14620 /* Inicia um temporizador entre bytes? */ 

14621 if (Itimeset && tp->tty termios.c cc[VMIN] > 0 

14622 && tp->tty termios.c cc[VTIME] > 0) 1 
14623 settimer(tp, TRUE); 

14624 timeset = TRUE; 

14625 } 

14626 } 

14627 

14628 /* Executa a complicada função de ecoamento. */ 

14629 if (tp->tty_termios.c_lflag & (ECHO|ECHONL)) ch = tty_echo(tp, ch); 
14630 

14631 /* Salva o caractere na fila de entrada. */ 

14632 *tp->tty_inhead++ = ch; 

14633 if (tp->tty_inhead == bufend(tp->tty_inbuf)) 

14634 tp->tty_inhead = tp->tty_inbuf; 

14635 tp->tty_incount++; 

14636 if (ch & IN EOT) tp->tty_eotct++; 

14637 

14638 /* Tenta terminar a saída se a fila ameaçar a estourar. */ 
14639 if (tp->tty_incount == buflen(tp->tty_inbuf)) in_transfer(tp); 
14640 } 

14641 return ct; 

14642 } 


14644 /*=========== * 
14645 X echo j 
14646 PCDS ee 
14647 PRIVATE int tty echo(tp, ch) 

14648 register tty t “tp; /* terminal no qual ecoar */ 

14649 register int ch; /* ponteiro para caractere a ecoar */ 
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14705 
14706 
14707 
14708 
14709 


A 


* Ecoa o caractere se o ecoamento estiver ativo. Alguns caracteres de controle são ecoados 
com seus efeitos normais, outros caracteres de controle são ecoados como "^X", 


os caracteres normais são ecoados diretamente. EOF (°D) é ecoado, mas imediatamente 


apagado com um retrocesso. Retorna o caractere com o comprimento ecoado adicionado 


em seus atributos. 
int len, rp; 


ch & “IN LEN; 
if (1 (tp->tty termios.c Tflag & ECHO)) 1 
if (ch == CAn” | IN EOT) && (tp->tty termios.c 1flag 
& (ICANON| ECHONL)) == (ICANON]| ECHONL)) 
(*tp->tty echo) (tp, “An'D; 
return(ch); 


} 


/* "Reprint" indica se a saída do eco foi bagunçada por outra saída. */ 
rp = tp->tty_incount == 0 ? FALSE : tp->tty_reprint; 


if (Cch & IN CHAR) <" °) { 
switch (ch & (IN ESC|IN EOF|IN EOT|IN CHAR)) { 


case “Mt”: 
len = 0; 
do { 
(*tp->tty_echo) (tp, > °); 
Ten++; 
} while (len < TAB SIZE && (tp->tty position & TAB MASK) != 0); 
break; 


case 'Nr” | IN EOT: 
case 'An” | IN EOT: 
(*tp->tty echo) (tp, ch & IN CHAR); 


len = 0; 
break; 
default: 
(*tp->tty echo) (tp, ""'); 
(*tp->tty echo) (tp, "Q' + (ch & IN CHAR)); 
len = 2; 
} 
} else 
if (Cch & IN CHAR) == ’\177°) { 
/* A DEL prints as "^°?". */ 
(*tp->tty_echo) (tp, ""'5; 
(*tp->tty_echo) (tp, "?'); 
len = 2; 
} else { 
(*tp->tty echo) (tp, ch & IN CHAR); 
len = 1; 


} 
if (ch & IN EOF) while Clen > 0) { (*tp->tty_echo)(tp, 'Nb'); len--; 3 


tp->tty_reprint = rp; 
return(ch | (len << IN_LSHIFT)); 


PRIVATE void rawecho(tp, ch) 
register tty t *tp; 
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14710 int ch; 

14711 { 

14712 /* Ecoa sem interpretação se ECHO estiver configurado. */ 
14713 int rp = tp->tty reprint; 

14714 if (tp->tty termios.c Iflag & ECHO) (*tp->tty echo) (tp, ch); 
14715 tp->tty reprint = rp; 

14716 + 


14718 /f====D=D>>=DD>55>205>05500 5000500525 DDDEDDDDDDSD==DD5D2DD2D=DDSDDDS=DEDDnDo 
14719 bi back over * 
14720 f=ooooD=D=D====DDD>DD000DDDDDDD0000DDDD00000DDDDDDcccnDoDDDcooonnoDoDconnno=*/ 
14721 PRIVATE int back over(tp) 

14722 register tty t *tp; 

14723 { 

14724 /* Retrocede para o caractere anterior na tela e o apaga. */ 

14725 ul6 t “head; 

14726 int len; 

14727 

14728 if (tp->tty incount == 0) return(0); /* fila vazia */ 

14729 head = tp->tty inhead; 

14730 if (head == tp->tty inbuf) head = bufend(tp->tty inbuf); 


14731 if (*--head & IN EOT) return(0); /* não pode apagar “quebras de linha” */ 
14732 if (tp->tty reprint) reprint(tp); /* reimprime se bagunçou */ 
14733 tp->tty inhead = head; 

14734 tp->tty incount--; 

14735 if (tp->tty termios.c 1flag & ECHOE) { 

14736 len = (*head & IN LEN) >> IN LSHIFT; 

14737 while (len > 0) { 

14738 rawecho(tp, 'Nb'); 

14739 rawecho(tp, >? °); 

14740 rawecho(tp, 'Nb'); 

14741 len--; 

14742 } 

14743 } 

14744 return(1); /* um caractere apagado */ 
14745 3 

14747 

14748 

14749 

14750 PRIVATE void reprint(tp) 

14751 register tty t *tp; /* ponteiro para estrutura tty */ 
14752 { 


14753 /* Restaura o que foi ecoado antes na tela, se a entrada do usuário foi 


14754 * bagunçada pela saída ou se REPRINT (^R) for digitado. 
14755 */ 

14756 int count; 

14757 ul6 t *head; 

14758 

14759 tp->tty reprint = FALSE; 

14760 

14761 /* Encontra a última quebra de linha na entrada. */ 
14762 head = tp->tty inhead; 

14763 count = tp->tty incount; 

14764 while (count > 0) { 

14765 if (head == tp->tty inbuf) head = bufend(tp->tty inbuf); 
14766 if Chead[-1] & IN EOT) break; 

14767 head--; 

14768 count--; 


14769 } 
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14770 if (count == tp->tty_incount) return; /* nenhum motivo para reimprimir */ 
14771 

14772 /* Mostra REPRINT (CR) e move para uma nova linha. */ 

14773 (void) tty_echo(tp, tp->tty_termios.c_cc[VREPRINT] | IN_ESC); 

14774 rawecho(tp, °\r’); 

14775 rawecho(tp, “An'D; 

14776 

14777 /* Reimprime da última quebra em diante. */ 

14778 do { 

14779 if (head == bufend(tp->tty inbuf)) head = tp->tty inbuf; 

14780 *head = tty echo(tp, *head); 

14781 head++; 

14782 count++; 

14783 } while (count < tp->tty incount); 

14784 3 

14786 

14787 * 
14788 = = ========== ==== === EJ 
14789 PUBLIC void out process(tp, bstart, bpos, icount, ocount) 

14790 tty_t *tp; 

14791 char *bstart, *bpos, *bend; /* start/pos/end of circular buffer */ 

14792 int *icount; /* carac. de entrada / carac. de entrada usados */ 
14793 int *ocount; /* carac. de saída max / carac. de saída usados */ 
14794 { 

14795 /* Realiza processamento de saída em um buffer circular. *icount é o número de 
14796 * bytes a processar e o número de bytes realmente processados no retorno. 

14797 * *ocount é o espaço disponível na entrada e o espaço usado na saída. 

14798 * (Naturalmente, *icount < *ocount.) A posição de coluna é atualizada pelo módulo 
14799 * de TAB, pois só precisamos disso para tabulações. 

14800 */ 

14801 

14802 int tablen; 

14803 int ict = *icount; 

14804 int oct = *ocount; 

14805 int pos = tp->tty_position; 

14806 

14807 while ÇCict > 0) { 

14808 switch (*bpos) { 

14809 case ’\7?’: 

14810 break; 

14811 case ’\b’: 

14812 pos--; 

14813 break; 

14814 case ’\r’: 

14815 pos = 0; 

14816 break; 

14817 case ’\n’: 

14818 if (C(tp->tty_termios.c_oflag & (OPOST |ONLCR)) 

14819 == (OPOST|ONLCR)) { 
14820 /* Faz o mapeamento de LF em CR+LF se houver espaço. Note que o 
14821 * próximo caractere no buffer é sobrescrito; portanto, 
14822 * paramos neste ponto. 

14823 R 

14824 if (oct >= 2) { 

14825 *bpos = 'Nr'; 

14826 if (4+bpos == bend) bpos = bstart; 

14827 *bpos = "An"; 

14828 pos = 0; 


14829 ict--; 
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14830 oct -= 2; 

14831 } 

14832 goto out_done; /* sem espaço ou o buffer foi alterado */ 
14833 } 

14834 break; 

14835 case ’\t’: 

14836 /* Melhor suposição para o comprimento da tabulação. */ 
14837 tablen = TAB_SIZE - (pos & TAB_MASK); 

14838 

14839 if (Ctp->tty_termios.c_oflag & (OPOST |XTABS)) 

14840 == (OPOST|XTABS)) { 
14841 /* As tabulações devem ser expandidas. */ 

14842 if (oct >= tablen) { 

14843 pos += tablen; 

14844 ict--; 

14845 oct -= tablen; 

14846 do { 

14847 *bpos =" ”; 

14848 if (4++bpos == bend) bpos = bstart; 
14849 } while (--tablen != 0); 

14850 } 

14851 goto out_done; 

14852 } 

14853 /* As tabulações são enviadas diretamente para a saída. */ 
14854 pos += tablen; 

14855 break; 

14856 default: 

14857 /* Presume que qualquer outro caractere seja impresso como um único. */ 
14858 pos++; 

14859 

14860 if (4++bpos == bend) bpos = bstart; 

14861 ict--; 

14862 oct--; 

14863 } 

14864 out done: 

14865 tp->tty position = pos & TAB MASK; 

14866 

14867 icount -= ict; /* [io]ct são o número de caracteres não usados */ 
14868 *ocount -= oct; /* *[io]count são o número de caracteres usados */ 
14869 3 


14871 /f====>=>=>>=>>>>=>=>>>>>=>>>>>>>>>">">==>>>==>">>"==>">>==>>"=—=>">==—-">————>———>========= * 
14872 x dev ioctl * 
14873  #======e ODE e] 
14874 PRIVATE void dev ioctl (tp) 

14875 tty t *tp; 


14876 1 

14877 /* As operações ioctl TCSETSW, TCSETSF e TCDRAIN esperam que a saída termine para 
14878 * certificar-se de que uma mudança de atributo não afete o processamento da saída 
14879 * corrente. Uma vez terminada a saída, a operação ioctl é executada como em do ioctT(). 
14880 */ 

14881 int result; 

14882 

14883 if (tp->tty outleft > 0) return; /* saída não concluída */ 

14884 

14885 if (tp->tty ioreq != TCDRAIN) 1 

14886 if (tp->tty ioreq == TCSETSF) tty icancel (tp); 

14887 result = sys vircopy(tp->tty ioproc, D, tp->tty iovir, 

14888 SELF, D, (vir bytes) &tp->tty termios, 


14889 (vir bytes) sizeof(tp->tty termios)); 
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setattr(tp); 


tp->tty ioreg = 0; 
tty reply(REVIVE, tp->tty iocaller, tp->tty ioproc, result); 


[/B==============>==>=>===>==>=>=>=>>=>>=>>=>==>=>=>=>>>>=>=>=>=>>>>>=>>>=>=>>>>=>>=>=>=>=>===> * 
i setattr * 
EEDDS====DD=D>=>>=>>>>=>>=>=>=>=>>=>>>>=>>>=>>=>>=>=>>>>=>=>>=>>=>>>>>>>>=>>=>>=>>=>>=>>>=>=>=>===> * / 
PRIVATE void setattr (tp) 
tty t “tp; 
{ 
/* Aplica os novos atributos de linha (bruto/canônico, velocidade da linha etc.) */ 
ul6 t *inp; 
int count; 


if (1(tp->tty termios.c Tflag & ICANON)) 1 
/* Modo bruto; coloca uma “quebra de linha” em todos os caracteres na fila de 
* entrada. É indefinido o que acontece com a fila de entrada quando ICANON é 
* desligado, um processo deve usar TCSAFLUSH para descarregar a fila. 
* Manter a fila para preservar a digitação antecipada é a “coisa certa a fazer”; 
* porém, quando um process usa TCSANOW para passar para o modo bruto. 
*/ 

count = tp->tty_eotct = tp->tty_incount; 
inp = tp->tty_intail; 
while (count > 0) { 

*inp |= IN EOT; 

if (++inp == bufend(tp->tty_inbuf)) inp = tp->tty_inbuf; 

--count; 


+o t 


} 


/* Inspeciona MIN e TIME. */ 
settimer(tp, FALSE); 
if (tp->tty termios.c Iflag & ICANON) { 
/* Não há MIN & TIME no modo canônico. */ 
tp->tty min = 1; 
} else { 
/* No modo bruto, MIN é o número de caracteres desejados e TIME é o 
* tempo a esperar por eles. Com exceções interessantes se um dos dois for zero. 
*/ 
tp->tty_min = tp->tty termios.c cc[VMIN]; 
if Ctp->tty min == 0 && tp->tty termios.c cc[VTIME] > 0) 
tp->tty min = 1; 
} 


if (!(tp->tty termios.c iflag & IXON)) { 
/* Não há controle de início/parada de saída; portanto, não deixa a saída inibida. * 
tp->tty_inhibited = RUNNING; 
tp->tty_events = 1; 


} 


/* Configurar a velocidade de saída como zero desliga o telefone. */ 
if (tp->tty_termios.c_ospeed == B0) sigchar(tp, SIGHUP); 


/* Configura velocidade da linha, tam. de carac. etc, no nível do dispositivo. */ 
(*tp->tty_ioctl)(tp, 0); 
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14949 | /$===D==DDDD=DDD==>>=>=>>>=>=>>>=>=>>>==>>===>D0000D0000D0=000=00>>=0>>>=>=>>==—= * 
14950 * tty_reply j 
14951  *=============== Ý 
14952 PUBLIC void tty_reply(code, replyee, proc_nr, status) 

14953 int code; /* TASK REPLY ou REVIVE */ 

14954 int replyee; /* endereço de destino da resposta */ 

14955 int proc_nr; /* para quem a resposta deve ir? */ 

14956 int status; /* código de resposta */ 

14957 { 

14958 /* Envia uma resposta para um processo que queria ler ou escrever dados. */ 
14959 message tty mess; 

14960 

14961 tty mess.m type = code; 

14962 tty mess.REP PROC NR = proc nr; 

14963 tty mess.REP STATUS = status; 

14964 

14965 if ((status = send(replyee, &tty mess)) != OK) { 

14966 panic("TTY","tty reply failed, statusÂn", status); 

14967 

14968 3 

14970 

14971 

14972 


14973 PUBLIC void sigchar(tp, sig) 
14974 register tty t *tp; 


14975 int sig; /* SIGINT, SIGQUIT, SIGKILL ou SIGHUP */ 

14976 | 

14977 /* Processa um caracter SIGINT, SIGQUIT ou SIGKILL do teclado ou SIGHUP de um 
14978 * fechamento de tty, "stty 0" ou um desligamento de RS-232 real. O MM enviará o sinal para 
14979 * o grupo do processo (INT, QUIT), para todos os processos (KILL) ou para o líder da sessão 
14980 * (HUP). 

14981 */ 

14982 int status; 

14983 

14984 if Ctp->tty pgrp != 0) 

14985 if (OK != (status = sys kill(tp->tty pgrp, sig))) 

14986 panic("TTY","Error, call to sys kill failed", status); 

14987 

14988 if (1 (tp->tty termios.c Tflag & NOFLSH)) 1 

14989 tp->tty incount = tp->tty eotct = 0; /* elimina entrada anterior */ 
14990 tp->tty intail = tp->tty inhead; 

14991 (*tp->tty ocancel) (tp, 0); /* elimina toda a saída */ 
14992 tp->tty inhibited = RUNNING; 

14993 tp->tty events = 1; 

14994 

14995 3 

14997 

14998 $ tty icancel * 
14999 ÉS SEDE / 


15000 PRIVATE void tty icancel (tp) 
15001 register tty t *tp; 


15002 { 

15003 /* Descarta toda saída pendente, buffer de tty ou dispositivo. */ 
15004 

15005 tp->tty incount = tp->tty eotct = 0; 

15006 tp->tty intail = tp->tty inhead; 


15007 (“tp->tty icancel) (tp, 0); 
15008 + 
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PRIVATE void tty initO 


{ 


/* Inicializa a estrutura tty e chama as rotinas de inicialização de dispositivo. */ 


register tty_t *tp; 
TNE S3 
struct sigaction sigact; 


/* Inicializa as linhas de terminal. */ 
for (tp = FIRST_TTY,s=0; tp < END_TTY; tp++,s++) { 


tp->tty_index = s; 
tmr inittimer(&tp->tty tmr); 


tp->tty intail = tp->tty inhead = tp->tty inbuf; 

tp->tty min = 1; 

tp->tty termios = termios defaults; 

tp->tty icancel = tp->tty ocancel = tp->tty ioctl = tp->tty close = 
tty devnop; 


if (tp < tty addr(NR CONS)) 1 
scr init(tp); 
tp->tty minor = CONS MINOR + s; 
+ else 
if (tp < tty addr(NR CONS+NR RS LINES)) { 
rs init(tp); 
tp->tty minor = RS232 MINOR + s-NR CONS; 
+ else { 
pty_init(tp); 
tp->tty minor = s - (NR CONS+NR RS LINES) + TTYPX MINOR; 


PRIVATE void tty timed out(timer t *tp) 


{ 


/* Este temporizador expirou. Ativa o flag de eventos para forçar o processamento. 


tty_t *tty_ptr; 

tty ptr = &tty_table[tmr_arg(tp)->ta_int]; 

tty_ptr->tty_min = 0; /* obriga a leitura a ter êxito */ 
tty_ptr->tty_events = 1; 


PRIVATE void expire_timers(void) 


{ 


/* Uma mensagem de alarme síncrono foi recebida. Verifica se existem temporizadores 


* expirados. Possivelmente, ativa o flag de evento e reprograma outro alarme. 
*/ 

clock_t now; /* tempo corrente */ 

int s; 


*/ 
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15069 

15070 /* Obtém o tempo corrente para comparar com os temporizadores. */ 

15071 if ((s=getuptime(&now)) != OK) 

15072 panic("TTY","Couldn't get uptime from clock.", s); 

15073 

15074 /* Varre a fila em busca de temporizadores expirados. Isso chama as funções cão de guarda 
15075 * de temporizadores expirados. Talvez, uma nova chamada de alarme deve ser escalonada. 
15076 */ 

15077 tmrs exptimers(&tty timers, now, NULL); 

15078 if (tty timers == NULL) tty next timeout = TMR NEVER; 

15079 else 1 /* configura novo alarme síncrono */ 
15080 tty next timeout = tty timers->tmr exp time; 

15081 if ((s=sys setalarm(tty next timeout, 1)) != OK) 

15082 panic("TTY","Couldn't set synchronous alarm.", s); 

15083 } 

15084 } 

15086"  /*========DD=DDDDDDD5DD=DD5DDDD55D>5DD=DDD=D==2D=2=>=D=D==2=D=2==>=>=>===========>=========== * 

15087 + settimer x 

15088 PCDS ee / 

15089 PRIVATE void settimer(tty ptr, enable) 

15090 tty t *tty ptr; /* Vinha para configurar ou desconfigurar um temporizador */ 
15091 int enable; /* Configura temporizador apenas se verdadeiro */ 

150922 { 

15093 clock t now; /* tempo corrente */ 


15094 clock t exp time; 
15095 int s; 


15096 

15097 /* Obtém o tempo corrente para calcular o tempo limite. */ 

15098 if ((s=getuptime(&now)) != OK) 

15099 panic("TTY","Couldn't get uptime from clock.", s); 

15100 if (enable) { 

15101 exp_time = now + tty_ptr->tty_termios.c_cc[VTIME] * (HZ/10); 

15102 /* Configura um novo temporizador para ativar os flags de eventos do TTY. */ 
15103 tmrs settimer(&tty timers, &tty_ptr->tty_tmr, 

15104 exp time, tty timed out, NULL); 

15105 } else { 

15106 /* Remove o temporizador das listas ativa e expirada. */ 

15107 tmrs_clrtimer(&tty_timers, &tty_ptr->tty_tmr, NULL); 

15108 } 

15109 

15110 /* Agora, verifica se um novo alarme deve ser reprogramado. Isso acontece quando o início 
15111 * da fila de temporizadores foi desativado ou reinserido em outra posição, ou 
15112 * quando um novo temporizador foi adicionado no início. 

15113 *y 

15114 if (tty_timers == NULL) tty next timeout = TMR_NEVER; 

15115 else if (tty_timers->tmr_exp_time != tty_next_timeout) { 

15116 tty_next_timeout = tty_timers->tmr_exp_time; 

15117 if ((s=sys setalarm(tty next timeout, 1)) != OK) 

15118 panic("TTY","Couldn't set synchronous alarm.", s); 

15119 } 

15120 3 

15122 A o 
15123 E tty devnop ii 
15124 0 f=oonoDDDDD====DDDDDD=0nDDDDDDooooDDDDDDoocoDDDDDococnDoDDDcoonnnoDoDcocono=*/ 


15125 PUBLIC int tty devnop(tp, try) 
15126 tty t *tp; 

15127 int try; 

15128 { 
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/* Algumas funções não precisam ser implementadas no nível do dispositivo. */ 


} 


Jinn 


PRIVATE void do_select(tp, m_ptr) 


register tty_t *tp; /* ponteiro para estrutura tty */ 
register message *m_ptr; /* ponteiro para a message enviada para a tarefa */ 
{ 


int ops, ready_ops = 0, watch; 


ops 


= m_ptr->PROC_NR & (SEL RD|SEL WR|SEL ERR); 
watch = 


(m ptr->PROC NR & SEL NOTIFY) ? 1 : 0; 
ready ops = select try(tp, ops); 
if C!ready ops && ops && watch) 1 


tp->tty select ops |= ops; 
tp->tty select proc = m ptr->m source; 


} 
tty_reply(TASK_REPLY, m_ptr->m_source, m_ptr->PROC_NR, ready_ops); 


return; 


HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HHH HH H+H HH HHHH ++ 


drivers/tty/keyboard.c 
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15200 
15201 
15202 
15203 
15204 
15205 
15206 
15207 
15208 
15209 
15210 
15211 
15212 
15213 
15214 
15215 
15216 
15217 
15218 
15219 
15220 
15221 
15222 
15223 
15224 


/* Driver de teclado para PCs e ATs. 


* Alterações: 
* 13 de julho de 2004 os processos podem observar teclas de função (Jorrit N. Herder) 
z 15 de junho de 2004 wreboot() removido, exceto nos dumps de pânico (Jorrit N. Herder) 


*/ 


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


04 de fevereiro de 1994 mapas de teclas carregáveis (Marcus Hampel) 


"../drivers.h" 
<sys/time.h> 
<sys/select.h> 
<termios.h> 
<signal.h> 

<unistd.h> 
<minix/callnr.h> 
<minix/com.h> 
<minix/keymap.h> 
"Ety.h” 
"keymaps/us-std.src” 
/../kernel/const.h" 
/../kernel/config.h" 
/../kernel/type.h"” 
/../kernel/proc.h” 


" 


int irq_hook_id = -1; 
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15225 
15226 
15227 
15228 
15229 
15230 
15231 
15232 
15233 


15234 


15235 
15236 
15237 


15238 
15239 
15240 
15241 
15242 
15243 
15244 
15245 
15246 
15247 
15248 
15249 
15250 
15251 
15252 
15253 
15254 
15255 
15256 
15257 
15258 
15259 
15260 
15261 
15262 
15263 
15264 
15265 
15266 
15267 
15268 
15269 
15270 
15271 
15272 
15273 
15274 
15275 
15276 
15277 
15278 
15279 
15280 
15281 
15282 
15283 
15284 


/* Teclado padrão e AT. 


tdefine KEYBD 0x60 


/* teclado AT. */ 


tdefine 
tdefine 
tdefine 
tdefine 


tdefine 
tdefine 
tdefine 
tdefine 


tdefine 


(PS/2 MCA implica em AT completamente.) */ 


/* porta de E/S para dados de teclado */ 


KB COMMAND 0x64 /* porta de E/S para comandos no AT */ 

KB STATUS 0x64 /* porta de E/S para status no AT */ 

KB ACK OxFA /* resposta do ack do teclado */ 

KB OUT FULL 0x01 /* bit de status ativado quando há pressionamento de 
tecla de caracter pendente */ 

KB IN FULL 0x02 /* bit de status ativado quando não está pronto para 
receber */ 

LED CODE OxED /* comando para teclado para ativar LEDs */ 

MAX KB ACK RETRIES 0x1000 /* tempos max para esperar por ack do teclado */ 

MAX KB BUSY RETRIES 0x1000 /* tempos max para fazer laço enquanto teclado 

está ocupado */ 
KBIT 0x80 /* bit usado para reconhecer caracteres no teclado */ 


/* Diversos. */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


tdefine 
tdefine 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 


PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 


/* Bits 
tdefine 
tdefine 
tdefine 


PRIVATE 


* tecla de reinicialização em situação de pânico */ 

* para reconhecer barra numérica */ 

* para distinguir shift da esquerda e da direita */ 

* primeira tecla no teclado numérico */ 

* INS para uso na reinicialização com CTRL-ALT-INS */ 
* DEL para uso na reinicialização com CTRL-ALT-DEL */ 


* número de linha para console */ 

* tamanho do buffer de entrada do teclado */ 
* buffer de entrada */ 

* próximo ponto livre no buffer de entrada */ 
* código de varredura a retornar para TTY */ 
* nº de códigos no buffer */ 


* código de varredura de escape detectado? */ 
* estado da tecla alt da esquerda */ 

* estado da tecla alt da direita */ 

* uma das duas teclas alt */ 

* estado da tecla control da esquerda */ 

* estado da tecla control da direita */ 

* uma das duas teclas control */ 

* estado da tecla shift da esquerda */ 

* estado da tecla shift da direita */ 

* uma das duas teclas shift */ 

* tecla num lock pressionada */ 

* tecla caps lock pressionada */ 

* tecla scroll lock pressionada */ 

* estado das teclas de lock por console */ 


E SC NANN 


ativos de tecla lock. Escolhidos iguais aos bits de LED do teclado. */ 


ESC SCAN 0x01 
SLASH SCAN 0x35 
RSHIFT SCAN 0x36 
HOME SCAN 0x47 
INS SCAN 0x52 
DEL SCAN 0x53 
CONSOLE 0 
KB IN BYTES 32 
char ibuf[KB IN BYTES]; 
char *ihead = ibuf; 
char *itail = ibuf; 
int icount; 

int esc; 

int altl; 

int alt r; 

int alt; 

ant ctrl; 

int ctrl r; 

int ctrl; 

int shift 1; 

int shift r; 

int shift; 

int num down; 

int caps down; 

int scroll down; 

int locks[NR CONS]; 
SCROLL LOCK 0x01 
NUM LOCK 0x02 
CAPS LOCK 0x04 
char numpad map[] = 


PHYLA, 


/* Variáveis e definição das teclas de função observadas. */ 
typedef struct observer { int proc nr; int events; } obs t; 
PRIVATE obs t fkey obs[12]; 
PRIVATE obs t sfkey obs[12]; 


/* observadores para F1-F12 */ 
/* observadores para SHIFT F1-F12 */ 


FORWARD | PROTOTYPE( int kb ack, (void) Ji 


FORWARD _PROTOTYPE(Ç int kb wait, 


(void) J3 
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15285 
15286 
15287 
15288 
15289 
15290 
15291 
15292 
15293 
15294 
15295 
15296 
15297 
15298 
15299 
15300 
15301 
15302 
15303 
15304 
15305 
15306 
15307 
15308 
15309 
15310 
15311 
15312 
15313 
15314 
15315 
15316 
15317 
15318 
15319 
15320 
15321 
15322 
15323 
15324 
15325 
15326 
15327 
15328 
15329 
15330 


15332 
15333 
15334 
15335 
15336 
15337 
15338 
15339 
15340 
15341 
15342 
15343 
15344 


FORWARD | PROTOTYPE( int func key, (int scode) ) 
FORWARD | PROTOTYPE( int scan keyboard, (void) ) 
FORWARD | PROTOTYPE( unsigned make break, (int scode) ) 
FORWARD _PROTOTYPE( void set_leds, (void) J3 
FORWARD _PROTOTYPE( void show key mappings, (void) J 
FORWARD _PROTOTYPE(Ç int kb read, (struct tty *tp, int try) ) 
FORWARD _PROTOTYPE( unsigned map key, (int scode) ) 


/* Faz o mapeamento de um código de varredura em um código ASCII, ignorando modificadores. 


#define map_key0(scode) \ 
(Cunsigned) keymap[(scode) * MAP_COLS]) 


PRIVATE unsigned map_key(scode) 
int scode; 
{ 


/* Faz o mapeamento de um código de varredura em um código ASCII. */ 


int caps, column, 1k; 
ul6 t *keyrow; 


if (scode == SLASH SCAN && esc) return '/"; /* não faz o mapeamento da barra numérica * 


keyrow = &keymap[scode * MAP COLS]; 


caps = shift; 

Ik = Tocks[ccurrent]; 

if CClIk & NUM LOCK) && HOME SCAN <= scode && scode <= DEL SCAN) caps = !caps; 
if (Clk & CAPS LOCK) && (keyrow[0] & HASCAPS)) caps = !caps; 


if (alt) { 
column = 2; 
if (ctrl || alt_r) column = 3; /* Ctrl + Alt == AltGr */ 
if (caps) column = 4; 
} else { 
column = 0; 
if (caps) column = 1; 
if (ctrl) column 55 


} 
return keyrow[column] & “HASCAPS; 


PUBLIC void kbd_interrupt(m_ptr) 
message *m_ptr; 


{ 
/* Ocorreu uma interrupção de teclado. Processa. */ 
int scode; 
static timer_t timer; /* o temporizador precisa ser static! */ 


/* Busca o caractere do hardware do teclado e o reconhece. */ 
scode = scan_keyboard(); 


*/ 
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15345 /* Armazena código de varredura na mem. para que a tarefa possa lê-lo posteriormente. */ 
15346 if (Cicount < KB IN BYTES) 1 

15347 *ijhead++ = scode; 

15348 if Cihead == ibuf + KB IN BYTES) ihead = ibuf; 

15349 icount++; 

15350 tty table[ccurrent].tty events = 1; 

15351 if (tty table[ccurrent].tty select ops & SEL RD) { 

15352 select retry(&tty table[ccurrent]); 

15353 } 

15354 } 

15355 } 

15357  /*==== eee * 
15358 T kb_read * 
15359 PCDS ee / 


15360 PRIVATE int kb read(tp, try) 
15361 tty t “tp; 
15362 int try; 


15363 { 

15364 /* Processa caracteres do buffer de teclado circular. */ 

15365 char buf[3]; 

15366 int scode; 

15367 unsigned ch; 

15368 

15369 tp = &tty table[ccurrent]; /* sempre usa o console corrente */ 
15370 

15371 if Ctry) { 

15372 if (icount > 0) return 1; 

15373 return 0; 

15374 } 

15375 

15376 while (icount > 0) { 

15377 scode = *itail++; /* pega um código de varredura de tecla */ 
15378 if Gitail == ibuf + KB IN BYTES) itail = ibuf; 

15379 icount--; 

15380 

15381 /* As teclas de função estão sendo usadas para dumps de depuração. */ 
15382 if (func key(scode)) continue; 

15383 

15384 /* Realiza processamento de make/break. */ 

15385 ch = make break(scode); 

15386 

15387 if (ch <= OxFF) { 

15388 /* Um caractere normal. */ 

15389 buf[0] = ch; 

15390 (void) in process(tp, buf, 1); 

15391 + else 

15392 if (HOME <= ch && ch <= INSRT) 1 

15393 /* Uma sequência de escape ASCII gerada pelo teclado numérico. */ 
15394 buf[0] = ESC; 

15395 buf[1] = '[’; 

15396 buf[2] = numpad map[ch - HOME]; 

15397 (void) in process(tp, buf, 3); 

15398 } else 

15399 if (ch == ALEFT) 1 

15400 /* Escolhe console de número menor como corrente. */ 
15401 select console(ccurrent - 1); 

15402 set leds); 

15403 } else 


15404 if (ch == ARIGHT) { 


APÊNDICE B e O CóDiGo-FONTE DO MINIX 


787 


15405 
15406 
15407 
15408 
15409 
15410 
15411 
15412 
15413 
15414 
15415 
15416 
15417 
15418 
15419 
15420 
15421 
15422 
15423 
15424 
15425 
15426 


15428 
15429 
15430 
15431 
15432 
15433 
15434 
15435 
15436 
15437 
15438 
15439 
15440 
15441 
15442 
15443 
15444 
15445 
15446 
15447 
15448 
15449 
15450 
15451 
15452 
15453 
15454 
15455 
15456 
15457 
15458 
15459 
15460 
15461 
15462 
15463 
15464 


/* Escolhe console de número maior como corrente. */ 
select console(ccurrent + 1); 


set leds( 
+ else 
if (AF1 <= ch && 


J3 


ch <= AF12) { 


/* Alt-F1 is console, Alt-F2 is ttycl, etc. */ 
select_console(ch - AF1); 


set_leds( 
} else 
if (CF1 <= ch && 
switch(ch) { 


J5 


ch <= CF12) { 


case CF1: show_key_mappings(); break; 
case CF3: toggle scrol1(); break; /* hardware <-> software */ 
case CF7: sigchar(&tty table[CONSOLE], SIGQUIT); break; 
case CF8: sigchar(&tty table[CONSOLE], SIGINT); break; 
case CF9: sigchar(&tty table[CONSOLE], SIGKILL); break; 
} 
} 

} 

return 1; 

} 

/* === ¥ 
* make break * 
di D======D==D>=>>>>=>>=>=>>=>>=>>=>>>>=>>=>>=>>=>>=>>>>=>>>>=>=>>>>>>>=>>=>>===>=>>=>>=>>=>=>==== * / 

PRIVATE unsigned make break(scode) 

int scode; /* código de varredura da tecla que acabou de ser pressionada ou liberada */ 


{ 


/* Esta rotina pode manipular teclados que interrompem apenas no pressionamento de teclas, 
* assim como teclados que interrompem no pressionamento e na liberação de teclas. 


* Por eficiência, a rotina de interrupção filtra a maioria das liberações de tecla. 


*/ 
int ch, make, escape; 
static int CAD_count = 


0; 


/* Verifica CTRL-ALT-DEL e, se encontrado, pára o computer. Isso seria 
* melhor se fosse feito em keyboard(), no caso de TTY ser desligado, exceto que control e 


* alt são configuradas 


no código de nível superior. 


*/ 
if (ctrl && alt && (scode == DEL SCAN || scode == INS SCAN)) 


{ 


if (++CAD_count == 3) sys abort(RBT HALT); 
sys kilICINIT PROC NR, SIGABRT); 


return -1; 


} 


/* Bit de ordem superior ativado na liberação da tecla. */ 


make = (scode & KEY_RELEASE) == 0; 
ch = map_key(scode &= ASCII_MASK); 


escape = esc; /* A tecla tem escape? (true, se foi adicionado desde o XT) */ 


esc = 0; 


switch (ch) { 
case CTRL: 


/* true, se pressionada */ 


/* mapeamento para ASCII */ 


/* Tecla control da esquerda ou da direita */ 


*(escape ? &cctrl r : &ctrl 1) = make; 
ctrl = ctrl 1 | ctrl r; 


break; 
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15465 case SHIFT: /* Tecla shift da esquerda ou da direita */ 
15466 *(scode == RSHIFT SCAN ? &shift r : &shift 1) = make; 
15467 shift = shift 1 | shiftr; 

15468 break; 

15469 case ALT: /* Tecla alt da esquerda ou da direita */ 
15470 *(escape ? &alt_r : &aalt 1) = make; 

15471 alt = alt 1 | alt rr; 

15472 break; 

15473 case CALOCK: /* Caps lock - alterna na transição de O -> 1 */ 
15474 if (caps down < make) 1 

15475 locks[ccurrent] “= CAPS LOCK; 

15476 set leds; 

15477 F 

15478 caps_down = make; 

15479 break; 

15480 case NLOCK: /* Num lock */ 

15481 if (num down < make) { 

15482 locks[ccurrent] ^= NUM LOCK; 

15483 set leds; 

15484 

15485 num down = make; 

15486 break; 

15487 case SLOCK: /* Scroll lock */ 

15488 if (scroll down < make) 1 

15489 locks[ccurrent] "= SCROLL LOCK; 

15490 set leds); 

15491 

15492 scroll down = make; 

15493 break; 

15494 case EXTKEY: /* Código de tecla de escape */ 

15495 esc = 1; /* A próxima tecla tem escape */ 
15496 return(-1); 

15497 default: /* Uma tecla normal */ 

15498 if (make) return(ch); 

15499 } 

15500 

15501 /* Libera tecla ou uma tecla tipo shift. */ 

15502 return(-1); 

15503 } 

15505 

15506 

15507 

15508 PRIVATE void set leds) 

15509 { 


15510 /* Configura os LEDs nas teclas caps, num e scroll lock */ 
15511 int ss 


15512 if (! machine.pc at) return; /* O PC/XT não tem LEDs */ 

15513 

15514 kb waitO; /* espera por buffer vazio */ 

15515 if ((s=sys outb(KEYBD, LED CODEJ) != OK) 

15516 printfC"wWarning, sys outb couldn't prepare for LED values: %d\n", s); 
15517 /* prepara o teclado para aceitar valores de LED */ 
15518 kb ackO; /* espera por resposta de rec */ 

15519 

15520 kb waitO; /* espera por buffer vazio */ 

15521 if ((s=sys outb(KEYBD, Tocks[ccurrent])) != OK) 

15522 printfC"wWarning, sys outb couldn't give LED values: %d\n", s); 

15523 /* give keyboard LED values */ 


15524 kb ackO; /* espera por resposta de rec */ 
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15525 


15527 
15528 
15529 
15530 
15531 
15532 
15533 
15534 
15535 
15536 
15537 
15538 
15539 
15540 
15541 
15542 
15543 
15544 
15545 
15546 
15547 


15549 
15550 
15551 
15552 
15553 
15554 
15555 
15556 
15557 
15558 
15559 
15560 
15561 
15562 
15563 
15564 
15565 
15566 
15567 


15569 
15570 
15571 
15572 
15573 
15574 
15575 
15576 
15577 
15578 


15580 
15581 
15582 
15583 
15584 


PRIVATE int kb wait O 


{ 


/* Espera que controladora fique pronta; 


int retries, status, temp; 
int 's; 


retries = MAX KB BUSY RETRIES + 1; /* espera até que não esteja ocupado 
do 1 
s = sys inb(KB STATUS, &status); 
if (status & KB OUT FULL) { 
s = sys inb(KEYBD, &temp); /* descarta valor */ 


} 
if (! (status & (KB_IN_FULL|KB_OUT_FULL)) ) 
break; /* espera até que esteja pronto */ 
} while (--retries != 0); 


retorna zero se atingir o tempo limite. 


*/ 


*/ 


/* continua, a não ser que atinja o tempo limite */ 


return(retries); /* zero ao atingir tempo limite, positivo se pronto */ 


PRIVATE int kb_ack©O 


{ 


/* Espera que o teclado reconheça último comando; 


int retries, S; 
u8_t u8val; 


retries = MAX_KB_ACK_RETRIES + 1; 
do { 
s = sys_inb(KEYBD, &u8val); 
if (u8val == KB_ACK) 


retorna zero se atingir tempo limite. 


break; /* wait for ack */ 
} while(--retries != 0); /* continue, a não ser que atinja o tempo limite*/ 
return(retries); /* diferente de zero se ack foi recebido */ 

} 

/* === ¥ 
+ kb init * 
ae E / 

PUBLIC void kb init(tp) 

tty t “tp; 

{ 

/* Inicializa o driver de teclado. */ 

tp->tty_devread = kb_read; /* função de entrada */ 

} 

/* mememe 2 O SO ES Ca O O E E e TT TT TT TT TT Tee eee eee eee 
* kb init once * 
[SR A sp e e e ca ep e e e 7 


PUBLIC void kb init once(void) 


{ 


*/ 
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15585 int i; 


15586 

15587 set leds); /* desliga o led de num lock */ 

15588 scan keyboard(); /* descarta toque de tecla restante */ 

15589 

15590 /* Limpa o array de observadores de tecla de função. Veja também func key(). 
15591 for (i=0; i<l2; i++) 1 

15592 fkey obs[i].proc nr = NONE; /* observadores de F1-F12 */ 

15593 fkey obs[il].events = 0; /* observadores de F1-F12 */ 

15594 sfkey obs[i].proc nr = NONE; /* observadores de Shift F1-F12 */ 
15595 sfkey obs[i].events = 0; /* observadores de Shift F1-F12 */ 
15596 

15597 

15598 /* Configura rotina de tratamento de interrupção e ativa IRQ de teclado. */ 
15599 irq hook id = KEYBOARD IRQ; /* id a ser retornada na interrupção */ 
15600 if (Ci=sys irgsetpolicy(KEYBOARD IRQ, IRQ REENABLE, &irq hook id)) != OK) 
15601 panic("TTY", "Couldn't set keyboard IRQ policy", i); 

15602 if (Ci=sys irgenable(&irq hook id)) != OK) 

15603 panic("TTY", "Couldn't enable keyboard IRQs", i); 

15604 kbd irq set |= (1 << KEYBOARD IRQ); 

15605 + 

15607 

15608 

15609 


15610 PUBLIC int kbd Toadmap (Cm) 

15611 message *m; 

15612 { 

15613 /* Carrega um novo mapa de teclas. */ 
15614 int result; 


15615 result = sys vircopy(m->PROC NR, D, (vir bytes) m->ADDRESS, 

15616 SELF, D, (vir bytes) keymap, 

15617 (vir bytes) sizeof(keymap)); 

15618 return(result); 

15619 3 

15621  /f=================>D==DD>=D=DD=D=2DD=DDD=DD>D=D=2=D==2D==>>>D=2=>==>==>==2=>==>============== * 
15622 ki do fkey ct] * 
15623 PEDE Dee / 
15624 PUBLIC void do fkey ctl(m ptr) 

15625 message “m ptr; /* ponteiro para a mensagem de requisição */ 
15626 { 

15627 /* Esta rotina permite que os processos registrem uma tecla de função para receber 
15628 * notificações se for pressionada. Pode existir no máximo um vínculo por tecla. 
15629 */ 

15630 int i? 

15631 int result; 

15632 

15633 switch (m ptr->FKEY REQUEST) 1 /* vê o que devemos fazer */ 

15634 case FKEY MAP: /* solicita novo mapeamento */ 

15635 result = OK; /* supõe que tudo estará ok*/ 

15636 for (i=0; i < 12; i++) 1 /* verifica as teclas F1-F12 */ 

15637 if (bit isset(m ptr->FKEY FKEYS, i+1) ) { 

15638 if (fkey obs[i].proc nr == NONE) { 

15639 fkey obs[il.proc nr = m ptr->m source; 

15640 fkey obs[il.events = 0; 

15641 bit unset(m ptr->FKEY FKEYS, i+1); 

15642 } else { 

15643 printf("WARNING, fkey map failed F%d\n", i+1); 


15644 result = EBUSY; /* relata a falha, mas tenta parar */ 
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15645 
15646 
15647 
15648 
15649 
15650 
15651 
15652 
15653 
15654 
15655 
15656 
15657 
15658 
15659 
15660 
15661 
15662 
15663 
15664 
15665 
15666 
15667 
15668 
15669 
15670 
15671 
15672 
15673 
15674 
15675 
15676 
15677 
15678 
15679 
15680 
15681 
15682 
15683 
15684 
15685 
15686 
15687 
15688 
15689 
15690 
15691 
15692 
15693 
15694 
15695 
15696 
15697 
15698 
15699 
15700 
15701 
15702 
15703 
15704 


} 
} 
; 
for (i=0; i < 12; i++) 1 /* verifica as teclas Shift+F1-F12 */ 
if (bit isset(m ptr->FKEY SFKEYS, i+1) ) { 
if (sfkey obs[il.proc nr == NONE) { 
sfkey obs[i].proc nr =m ptr->m source; 
sfkey obs[i].events = 0; 
bit unset(m ptr->FKEY SFKEYS, 1+1); 
} else { 
printfC("WARNING, fkey map failed Shift F%d\n", i+1); 
result = EBUSY; /* relata a falha, mas tenta parar */ 
} 
J 
} 
break; 
case FKEY_UNMAP: 
result = OK; /* supõe que tudo estará ok*/ 
for (i=0; i < 12; i++) { /* verifica as teclas F1-F12 */ 
if (bit isset(m ptr->FKEY FKEYS, i+1) ) { 
if (fkey obs[i].proc nr == m ptr->m source) 1 
fkey obs[il.proc nr = NONE; 
fkey obs[il.events = 0; 
bit unset(m ptr->FKEY FKEYS, i+1); 
} else { 
result = EPERM; /* relata a falha, mas tenta parar */ 
} 
} 
} 
for (i=0; i < 12; i++) { /* verifica as teclas Shift+F1-F12 */ 
if (bit_isset(m_ptr->FKEY_SFKEYS, i+1) ) { 
if (sfkey_obs[i].proc_nr == m_ptr->m_source) { 
sfkey_obs[i].proc_nr = NONE; 
sfkey obs[i].events = 0; 
bit_unset(m_ptr->FKEY_SFKEYS, i+1); 
} else { 
result = EPERM; /* relata a falha, mas tenta parar */ 
} 
} 
} 
break; 


case FKEY_EVENTS: 
m_ptr->FKEY_FKEYS = m_ptr->FKEY_SFKEYS = 0; 
for (i=0; i < 12; i++) { /* check (Shift+) F1-F12 keys */ 
if (fkey obs[i].proc nr == m_ptr->m_source) { 
if (fkey obs[i].events) 1 
bit set(m ptr->FKEY FKEYS, i+1); 
fkey obs[il.events = 0; 
} 


if (sfkey obs[il.proc nr == m_ptr->m_source) { 
if (sfkey obs[i].events) 1 
bit set(m ptr->FKEY SFKEYS, 1+1); 
sfkey obs[i].events = 0; 


i 
} 
break; 
default: 
result = EINVAL; /* tecla não pode ser observada */ 
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15705 
15706 
15707 
15708 
15709 
15710 


15712 
15713 
15714 
15715 
15716 
15717 
15718 
15719 
15720 
15721 
15722 
15723 
15724 
15725 
15726 
15727 
15728 
15729 
15730 
15731 
15732 
15733 
15734 
15735 
15736 
15737 
15738 
15739 
15740 
15741 
15742 
15743 
15744 
15745 
15746 
15747 
15748 
15749 
15750 
15751 
15752 
15753 
15754 
15755 
15756 
15757 
15758 


15760 
15761 
15762 
15763 
15764 


} 


/* Quase pronto, retorna o resultado para o processo que fez a chamada. */ 
m_ptr->m_type = result; 
send(m_ptr->m_source, m_ptr); 


PRIVATE int func key(scode) 
int scode; /* código de varredura para uma tecla de função */ 


{ 
/* Esta rotina captura teclas de função para propósitos de depuração. Os observadores 

* de teclas de função são mantidos em um array global. Se um sujeito (uma tecla) for 

* pressionado o observador será notificado do evento. A inicialização dos arrays é feita 
em kb_init, onde NONE é configurado para indicar que não há interesse na tecla. 
Retorna FALSE em um pressionamento de tecla ou se a tecla não pode ser observada. 


* 


a 


#/ 
message m; 
int key; 
int proc_nr; 
int i,s; 


/* Ignora liberação de tecla. Se for pressionamento, obtém o código completo da tecla. */ 
if (scode & KEY RELEASE) return(FALSE); /* liberação de tecla */ 
key = map key(scode); /* inclui modificadores */ 


/* Tecla pressionada, agora vê se existe um observador para a tecla pressionada. 
z Os observadores de F1-F12 estão no array fkey_obs. 
+ Os observadores de SHIFT F1-F12 estão no array sfkey_req. 
x CTRL F1-F12 reservadas (veja kb_read) 
* ALT F1-F12 reservadas (veja kb read) 
* Outras combinações não estão em uso. Note que Alt+Shift+F1-F12 ainda é 
* definida em <minix/keymap.h> e, assim, é fácil para extensões futuras. 
*/ 
if (F1 <= key && key <= F12) { = EISRIZ: &/ 
proc nr = fkey obs[key - Fl].proc nr; 
fkey obs[key - Fl].events ++ ; 
} else if (SF1 <= key && key <= SF12) { /* Shift F2-F12 */ 
proc nr = sfkey obs[key - SF1].proc nr; 
sfkey obs[key - SF1] .events ++; 


} 
else { 

return(FALSE); /* não observável */ 
} 


/* Vê se um observador está registrado e envia uma mensagem para ele. */ 
if (proc nr != NONE) { 
m.NOTIFY TYPE = FKEY PRESSED; 
notify(proc nr); 
} 
return(TRUE); 


PRIVATE void show_key_mappings O 
{ 
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15765 
15766 
15767 
15768 
15769 
15770 
15771 
15772 
15773 
15774 
15775 
15776 
15777 
15778 
15779 
15780 
15781 
15782 
15783 
15784 
15785 
15786 
15787 
15788 
15789 
15790 
15791 
15792 
15793 
15794 
15795 


15797 
15798 
15799 
15800 
15801 
15802 
15803 
15804 
15805 
15806 
15807 
15808 
15809 
15810 
15811 
15812 
15813 
15814 


15816 
15817 
15818 
15819 
15820 
15821 
15822 
15823 
15824 


int i,s; 
struct proc proc; 


printf("\n"); 

printf("System information. Known function key mappings to request debug dumps:\n"); 
printfiQ!========== === == 000 000000000 0000000000 000000000 0000000000 000000000 00 000000 Ws 
for (i=0; i<12; i++) { 


printf(" %sF%d: ", i+1<10? " ":"", i+1); 

if (fkey_obs[i].proc_nr != NONE) { 
if ((s=sys getproc(&proc, fkey_obs[i].proc_nr))!=0K) 

printf("sys_getproc: %d\n", s); 

printf("%-14.14s", proc.p_name); 

} else { 
printf("%-14.14s", "<none>"); 

} 


printf(" %sShift-F%d: ", i+1<10? " ":"", i+1); 
if (sfkey_obs[i].proc_nr != NONE) { 
if ((s=sys getproc(&proc, sfkey_obs[i].proc_nr))!=0K) 
printf("sys_getproc: %d\n", s); 
printf("%-14.14s", proc.p_name); 
} else { 
printf("%-14.14s", "<none>"); 
; 
printfCAn'D; 
} 
printfCAn'D; 
printf("Press one of the registered function key to trigger a debug dump.\n"); 
printfCAn'D; 


} 
Jrone a 
X scan_keyboard * 
Poe a a a a E 
PRIVATE int scan keyboard() 
{ 
/* Busca o caractere do hardware do teclado e o reconhece. */ 
pvb pair t byte in[2], byte_out[2]; 
byte in[0].port = KEYBD; /* obtém o código de varredura da tecla pressionada */ 
byte in[1].port = PORT B; /* strobe no teclado para reconhecer o caracter */ 


sys vinb(byte in, 2); /* solicita a entrada real */ 


pv set(byte out[0], PORT B, byte in[1].value | KBIT); /* strobe no bit superior */ 


pv set(byte out[1], PORT B, byte in[1].value); /* então, strobe no inferior */ 
sys voutb(byte out, 2); /* solicita a saída real */ 
return(byte in[0].value); /* retorna código de varredura */ 

} 

JŽ ======== * 

há do panic dumps * 
o, 

PUBLIC void do panic dumps (m) 

message *m; /* mensagem de requisição para TTY */ 

{ 


/* Espera toques de tecla para imprimir informações de depuração e reinicializar. */ 
int quiet, code; 
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15825 
15826 
15827 
15828 
15829 
15830 
15831 
15832 
15833 
15834 
15835 
15836 
15837 
15838 
15839 
15840 
15841 
15842 
15843 
15844 
15845 
15846 
15847 
15848 
15849 
15850 
15851 
15852 
15853 
15854 
15855 


/* Um pânico! Permite dumps de depuração até que o usuário queira desligar. */ 
printfCNnHit ESC to reboot, DEL to shutdown, F-keys for debug dumps\n"); 


(void) scan keyboard(; /* reconhece qualquer entrada antiga */ 

quiet = scan keyboard();/* valor quiescente (0 no PC, último código no AT)*/ 

for GD) 1 
tickdelay (10); 
/* Vê se existe requisição de saída pendente, mas não bloqueia. O diagnóstico 
* pode abranger várias funções printf; portanto, faz isso em um laço. 


while (nb receive(ANY, m) == OK) 1 
switch(m->m type) 1 


case FKEY CONTROL: do fkey ct1 (Cm); break; 
case SYS SIG: do new kmess(m); break; 
case DIAGNOSTICS: do diagnostics(m); break; 
default: P /* não faz nada */ 

} 

tickdelay(1); /* permite mais */ 


} 
code = scan keyboard(); 
if (code != quiet) 1 
/* Uma tecla foi pressionada. */ 


switch (code) { /* possivelmente, aborta o MINIX */ 
case ESC SCAN: sys abort(RBT REBOOT); return; 

case DEL SCAN: sys abort(RBT HALT); return; 

} 

(void) func_key(code); /* verifica tecla de função */ 


quiet = scan keyboard(); 


HEHEHEHEHE H+ HH HHHH HHHH HH HH HH HHH H+H HHHH HHHH HHHH H+H HHHH H+ HH HHHH H+H+HH+H+H+H+H+H+ 


drivers/tty/console.c 


HHHEHEHHHHHHH HHHH HHH HH H+H H+ HHHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH HHHH HH+H+HH+H+H+H+H+H+ 


15900 
15901 
15902 
15903 
15904 
15905 
15906 
15907 
15908 
15909 
15910 
15911 
15912 
15913 
15914 
15915 
15916 
15917 
15918 
15919 


/* 


Código e dados para o driver de console IBM. 


A controladora de vídeo 6845 usada pelo IBM PC compartilha sua memória de vídeo com 
a CPU no banco de memória 0xB0000. Para a 6845, essa memória 


* consiste em palavras de 16 bits. Cada palavra tem um código de caractere no byte inferior 
* e um assim chamado byte de atributo no byte superior. A CPU modifica diretamente 


#i 
#i 


*/ 


a memória de vídeo para exibir caracteres e configura dois registradores na 6845 que 
especificam a origem e a posição do cursor. A origem é o lugar na memória de vídeo 
onde o primeiro caractere (canto superior esquerdo) pode ser encontrado. Mover 

a origem é uma maneira rápida de rolar a tela. Alguns adaptadores de vídeo fazem 

a mudança automática da parte superior da memória de vídeo, para que a origem possa 
mover sem restrições. Para outros adaptadores, a memória de tela às vezes deve ser 
movida para reconfigurar a origem. Todos os cálculos na memória de vídeo usam endereços 
de caractere (palavra) por simplicidade e presumem que não há mudança automática. As 
funções de suporte em assembly transformam os endereços de palavra em endereços de byte 
e a função de rolagem se preocupa com a mudança automática. 


" 


nclude "../drivers.h" 
nclude <termios.h> 
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15920 
15921 
15922 
15923 
15924 
15925 
15926 
15927 
15928 
15929 
15930 
15931 
15932 
15933 
15934 
15935 
15936 
15937 
15938 
15939 
15940 
15941 
15942 
15943 
15944 
15945 
15946 
15947 
15948 
15949 
15950 
15951 
15952 
15953 
15954 
15955 
15956 
15957 
15958 
15959 
15960 
15961 
15962 
15963 
15964 
15965 
15966 
15967 
15968 
15969 
15970 
15971 
15972 
15973 
15974 
15975 
15976 
15977 
15978 
15979 


tinclude 
tinclude 
tinclude 


tinclude 
tinclude 
tinclude 


<minix/callnr.h> 
<minix/com.h> 
VEtydh 


"../../kernel/const.h" 


"../../kernel/config.h” 


"../../kernel/type.h" 


/* Definições usadas pelo driver de console. */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


MONO BASE 0xB0000L 
COLOR BASE  0xB8000L 
MONO SIZE 0x1000 
COLOR SIZE 0x4000 
EGA SIZE 0x8000 
BLANK COLO 0x0700 
SCROLL UP 0 
SCROLL DOWN 1 
BLANK MEM ((u16_t *) 0) 
CONS RAM WORDS 80 
MAX ESC PARMS 4 


/* Constantes relaciondas com os chips controladores. */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


/* Gerad 
tdefine 
tdefine 


M 6845 0x3B4 
Cc 6845 0x3D4 
INDEX 0 
DATA 1 
STATUS 6 
VID ORG 12 
CURSOR 14 
or de bip. */ 

BEEP FREQ 0x0533 
B TIME 3 


/* definições usadas para gerenciamento de fonts */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


GA SEQUENCER INDEX 
GA SEQUENCER DATA 
GA GRAPHICS INDEX 
GA GRAPHICS DATA 
GA VIDEO ADDRESS 
GA FONT SIZE 


/* Variáveis globais usadas pelo driver de console e pelo suporte em assembly. 


PUBLIC i 
PUBLIC u 
PUBLIC v 
PUBLIC u 
PUBLIC u 


PUBLIC unsigned blank color = BLANK COLOR; 


nt vid index; 
16 t vid seg; 
ir bytes vid off; 
nsigned vid size; 
nsigned vid mask; 


*/ 


gA 


/* base da memória de vídeo mono */ 

/* base da memória de vídeo em cores */ 

/* memória de vídeo mono de 4K */ 

/* memória de vídeo em cores de 16K */ 

/* EGA & VGA têm pelo menos 32K */ 

/* determina a cor do cursor em tela em branco 

/* rola para frente */ 

/* rola para trás */ 

/* diz para que mem_vid_copy() deixe a tela em branco */ 
/* tamanho do buffer da ram de vídeo */ 

/* número de params de sequência de escape permitidos */ 
/* porta para 6845 mono */ 

/* porta para 6845 em cores */ 

/* registrador de índice da 6845 */ 

/* registrador de dados da 6845 */ 

/* registrador de status da 6845 */ 

/* registrador de origem da 6845 */ 

/* registrador de cursor da 6845 */ 

/* valor do temporizador para configurar a freq do bip */ 
/* comprimento do bip CTRL-G é em tiques */ 

0x3C4 

0x3C5 

0x3CE 

0x3CF 

0xA0000L 

8192 

/* índice do segmento de vídeo no mapa de mem remoto */ 
/* ram de vídeo encontrada em vid seg:vid off */ 


/* 0x2000 para cor ou 0x0800 para mono */ 
/* O0x1FFF para cor ou 0x07FF para mono */ 


/* Variáveis privadas usadas pelo driver de console. */ 

* porta de E/S para acessar a 6845 */ 

* o hardware pode fazer a mudança automática? 
* 1 = rolagem por software, O = hardware */ 

* o alto-falante está fazendo o bip soar? */ 
* linhas de fonte por caractere */ 


PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 
PRIVATE 


int vid port; 

int wrap; 

int softscrolT; 

int beeping; 
unsigned font lines; 
unsigned scr width; 
unsigned scr lines; 
unsigned scr size; 


Eee 


* nº de caracteres em uma linha */ 


t nº de linhas na tela */ 


* nº de caracteres na tela */ 


/* código de exibição para branco */ 


*/ 
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15980 
15981 
15982 
15983 
15984 
15985 
15986 
15987 
15988 
15989 
15990 
15991 
15992 
15993 
15994 
15995 
15996 
15997 
15998 
15999 
16000 
16001 
16002 
16003 
16004 
16005 
16006 
16007 
16008 
16009 
16010 
16011 
16012 
16013 
16014 
16015 
16016 
16017 
16018 
16019 
16020 
16021 
16022 
16023 
16024 
16025 
16026 
16027 
16028 
16029 
16030 
16031 
16032 
16033 
16034 
16035 
16036 
16037 
16038 
16039 


/* Dados por console. */ 
typedef struct console { 


tty t *c tty; 

int c_column; 

int c_row; 

int c rwords; 
unsigned c start; 
unsigned c limit; 
unsigned c org; 
unsigned c cur; 
unsigned c attr; 
unsigned c blank; 
char c reverse; 
char c esc state; 
char c esc intro; 
int *c esc parmp; 


* estrutura TTY associada */ 

* número de coluna corrente (0-origem) */ 

* linha corrente (0 no topo da tela) */ 

* número de PALAVRAS (não bytes) na fila de saída */ 
* início da memória de vídeo deste console */ 

* limite da memória de vídeo deste console */ 

* posição na RAM onde a base do 6845 aponta */ 
* posição corrente do cursor na RAM de vídeo */ 
* atributos de caractere */ 

* atributo de branco */ 

* vídeo reverso */ 

* O=normal, 1=ESC, 2=ESC[ */ 

* Distinguindo caractere após ESC */ 

/* ponteiro para parâmetro de escape corrente */ 


DR E 


int c esc parmv[MAX ESC PARMS]; /* lista de parâmetros de escape */ 
ul6 t c ramqueue[CONS RAM WORDS] ; /* buffer para RAM de vídeo */ 

+ console t; 

PRIVATE int nr cons= 1; /* número real de consoles */ 

PRIVATE console t cons table[NR CONS]; 

PRIVATE console t *curcons; /* correntemente visível */ 


/* Cor, se estiver usando uma controladora em cores. */ 
tdefine color (vid port == C 6845) 


/* Mapa de cores ANSI para os atributos usados pelo PC */ 
PRIVATE int ansi colors[8] = 10, 4, 2, 6, 1, 5, 3, 75; 


/* Estrutura usada para gerenciamento de fonte */ 


struct sequence { 


unsigned short index; 
unsigned char port; 
unsigned char value; 


3; 

FORWARD . PROTOTYPE( 
FORWARD . PROTOTYPE( 
FORWARD  PROTOTYPE( 
FORWARD  PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD - PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD  PROTOTYPE( 
FORWARD  PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD _PROTOTYPE( 
FORWARD  PROTOTYPE( 
FORWARD  PROTOTYPE( 
J * == 


int cons_write, (struct tty *tp, int try) ) 
void cons_echo, (tty_t *tp, int c) ) 
void out_char, (console_t *cons, int c) J 
void putk, (int c) ) 
void beep, (void) D) 
void do_escape, (console_t *cons, int c) ) 
void flush, (console t *cons) ) 
void parse_escape, (console_t *cons, int c) ) 
void scroll screen, (console t *cons, int dir) ) 
void set_6845, (int reg, unsigned val) ) 
void get 6845, (int reg, unsigned *val) ) 
void stop_beep, (timer_t *tmrp) 3 
void cons org0, (void) J 
int ga_program, (struct sequence *seq) ) 
int cons_ioctl, (tty_t *tp, int) ) 


PRIVATE int cons write(tp, try) 


register struct tty 
int try; 
{ 


*tp; /* tells which terminal is to be used */ 
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16040 
16041 
16042 
16043 
16044 
16045 
16046 
16047 
16048 
16049 
16050 
16051 
16052 
16053 
16054 
16055 
16056 
16057 
16058 
16059 
16060 
16061 
16062 
16063 
16064 
16065 
16066 
16067 
16068 
16069 
16070 
16071 
16072 
16073 
16074 
16075 
16076 
16077 
16078 
16079 
16080 
16081 
16082 
16083 
16084 
16085 
16086 
16087 
16088 
16089 
16090 
16091 
16092 
16093 
16094 
16095 
16096 
16097 
16098 
16099 


/* Copia o máximo de dados possível na fila de saída e, então, inicia a E/S. Nos 
* terminais mapeados na memória, como o console IBM, a E/S também será 
* concluída a as contagens atualizadas. Fica repetindo até que toda E/S esteja pronta. 


ré 


int count; 

int result; 

register char *tbuf; 

char buf[64]; 

console t *cons = tp->tty priv; 


if (try) return 1; /* sempre podemos escrever no console */ 


/* Verifica rapidamente se não há nada a fazer; portanto, isso pode ser chamado 
* frequentemente, sem testes não modulares em outros lugares. 


*/ 
if ((count = tp->tty outleft) == 0 || tp->tty inhibited) return; 


/* Copia os bytes do usuário em buf[] para endereçá-los decentemente. Faz laço pelas 
* cópias, pois o buffer de usuário pode ser muito maior do que buf[]. 
#7 
do { 

if (count > sizeof(buf)) count = sizeof(buf); 

if (Cresult = sys_vircopy(tp->tty_outproc, D, tp->tty out vir, 

SELF, D, (vir_bytes) buf, (vir_bytes) count)) != 0K) 
break; 
tbuf = buf; 


/* Atualiza a estrutura de dados do terminal. */ 
tp->tty_out_vir += count; 
tp->tty_outcum += count; 
tp->tty_outleft -= count; 


/* Produz a saída de cada byte da cópia na tela. Evita chamar 


* out char() para os caracteres "fáceis", os coloca no buffer 
* diretamente. 


do 1 
if CCunsigned) *tbuf < °? °? || cons->c esc state > 0 
|| cons->c column >= scr width 
|| cons->c rwords >= buflen(cons->c ramqueue)) 


{ 
out char(cons, *tbuf++); 
} else { 
cons->c_ramqueue[cons->c_rwords++] = 
cons->c_attr | (*tbuf++ & BYTE); 
cons->c_column++; 
} 


+ while (--count != 0); 
} while ((count = tp->tty outleft) != 0 && !tp->tty inhibited); 


flush(cons); /* transfere para a tela tudo que estiver no buffer */ 


/* Responde para o escritor se toda saída tiver terminado ou se ocorreu um erro. */ 
if (tp->tty outleft == 0 || result != OK) 1 
/* REVIVE não é possível. A E/S em consoles mapeados na memória termina. */ 
tty reply(tp->tty outrepcode, tp->tty outcaller, tp->tty outproc, 
tp->tty outcum); 
tp->tty outcum = 0; 
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16100 + 

16102  /*==========>D>>">>D=5" n ¥ 
16103 * cons echo ai 
16104 sp pqp a pj 
16105 PRIVATE void cons echo(tp, c) 

16106 register tty t *tp; /* ponteiro para estrutura tty */ 

16107 int c; /* caractere a ser ecoado */ 

16108 { 

16109 /* Ecoa entrada do teclado (imprime & descarrega). */ 

16110 console_t *cons = tp->tty_priv; 

16111 

16112 out char(cons, c); 

16113 flush(cons); 

16114 } 

16116 

16117 

16118 

16119 PRIVATE void out char(cons, c) 

16120 register console t *cons; /* ponteiro para estrutura console */ 

16121 int c; /* caractere a aparecer na saída */ 

16122 { 


16123 /* Produz a saída de um caractere no console. Verifica as sequências de escape primeiro. */ 
16124 if (cons->c esc state > 0) { 

16125 parse escape(cons, Cc); 

16126 return; 

16127 

16128 

16129 switch(c) { 

16130 case 000: /* nulo é normalmente usado para preenchimento */ 
16131 return; /* melhor não fazer nada */ 

16132 

16133 case 007: /* toca a campainha */ 

16134 flush(cons); /* imprime todos os caracteres enfileirados para saída */ 
16135 beep; 

16136 return; 

16137 

16138 case ’\b’: /* retrocesso */ 

16139 if (--cons->c column < 0) { 

16140 if (--cons->c row >= 0) cons->c colum += scr width; 
16141 } 

16142 flush(cons); 

16143 return; 

16144 

16145 case “An': /* line feed */ 

16146 if (C(cons->c tty->tty termios.c a & (OPOST|ONLCR)) 

16147 = (OPOST|ONLCR)) { 

16148 cons->c column = 0; 

16149 + 

16150 /*FALL THROUGH*/ 

16151 case 013: /* CTRL-K */ 

16152 case 014: /* CTRL-L */ 

16153 if (cons->c row == scr lines-1) 1 

16154 scroll] screen(cons, SCROLL UP); 

16155 } else { 

16156 cons->c row++; 

16157 E 

16158 flush(cons); 

16159 return; 
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16160 

16161 case 'Nr': /* carriage return */ 

16162 cons->c column = 0; 

16163 flush(cons); 

16164 return; 

16165 

16166 case “Nt': /* tabulação */ 

16167 cons->c column = (cons->c column + TAB SIZE) & “TAB MASK; 
16168 if (cons->c column > scr width) { 

16169 cons->c column -= scr width; 

16170 if (cons->c row == scr lines-1) { 

16171 scroll screen(cons, SCROLL UP); 

16172 } else { 

16173 cons->C_rOw++; 

16174 } 

16175 } 

16176 flush(cons); 

16177 return; 

16178 

16179 case 033: /* ESC - início de uma sequência de escape */ 
16180 flush(cons); /* imprime todos os caracteres enfileirados para saída */ 
16181 cons->c esc state = 1; /* marca ESC como visto */ 

16182 return; 

16183 

16184 default: /* os caracteres imprimíveis são armazenados em ramqueue */ 
16185 if (cons->c column >= scr width) { 

16186 if (CILINEWRAP) return; 

16187 if (cons->c row == scr lines-1) 1 

16188 scroll] screen(cons, SCROLL UP); 

16189 } else { 

16190 cons->C_rOw++; 

16191 } 

16192 cons->c_column = 0; 

16193 flush(cons); 

16194 } 

16195 if (cons->c rwords == buflen(cons->c_ramqueue)) flush(cons); 
16196 cons->c ramqueue[cons->c rwords++] = cons->c attr | (c & BYTE); 
16197 cons->c column++; /* next column */ 
16198 return; 

16199 } 

16200 } 


16202 

16203 x 

16204 kee 

16205 PRIVATE void scroll_screen(cons, dir) 

16206 register console_t *cons; /* ponteiro para estrutura console */ 

16207 int dir; /* SCROLL UP or SCROLL DOWN */ 

16208 { 

16209 unsigned new line, new org, chars; 

16210 

16211 flush(cons); 

16212 chars = scr size - scr width; /* uma tela menos uma linha */ 

16213 

16214 /* Rolar a tela é um incômodo real, devido às várias placas de vídeo 

16215 * incompatíveis. Este driver suporta rolagem por software (Hercules?), 

16216 * rolagem por hardware (placas mono e CGA) e rolagem por hardware sem 

16217 * mudança automática (placas EGA). Neste último caso, devemos nos certificarmos de que 

16218 x c_start <= c_org && c_org + scr_size <= c_limit 

16219 * valha, pois a placa EGA não muda automaticamente para o início após o final da 
memória de vídeo. 
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16220 
16221 
16222 
16223 
16224 
16225 
16226 
16227 
16228 
16229 
16230 
16231 
16232 
16233 
16234 
16235 
16236 
16237 
16238 
16239 
16240 
16241 
16242 
16243 
16244 
16245 
16246 
16247 
16248 
16249 
16250 
16251 
16252 
16253 
16254 


16256 
16257 
16258 
16259 
16260 
16261 
16262 
16263 
16264 
16265 
16266 
16267 
16268 
16269 
16270 
16271 
16272 
16273 
16274 
16275 
16276 
16277 
16278 
16279 


*/ 
if (dir == SCROLL_UP) { 


/* Rola linha para cima de 3 maneiras: soft, sem mudança automática, origem. */ 


if (softscroll) { 
vid_vid_copy(cons->c_start + scr width, cons->c start, chars); 
+ else 
if Clwrap && cons->c org + scr size + scr width >= cons->c limit) { 
vid vid copy(cons->c org + scr width, cons->c start, chars); 
cons->c org = cons->c start; 
+ else £ 
cons->c org = (cons->c org + scr width) & vid mask; 
} 
new_line = (cons->c_org + chars) & vid_mask; 
} else { 
/* Rola linha para baixo de 3 maneiras: soft, sem mudança automática, origem. 
if (softscroll) { 
vid vid copy(cons->c start, cons->c_start + scr width, chars); 
+ else 
if CIwrap && cons->c org < cons->c start + scr width) 1 
new org = cons->c limit - scr size; 
vid vid copy(cons->c org, new org + scr width, chars); 
cons->c org = new org; 
} else { 
cons->c_org = (cons->c_org - scr_width) & vid_mask; 
} 
new_line = cons->c_org; 
} 
/* Limpa a nova linha no início ou no fim. */ 
blank_color = cons->c_blank; 
mem_vid_copy(BLANK_MEM, new_line, scr_width); 


/* Configura a nova origem do vídeo. */ 
if (cons == curcons) set 6845(VID ORG, cons->c_org); 


flush(cons); 

} 

/* === ¥ 
i flush z 
EE / 

PRIVATE void flush(cons) 

register console t *cons; /* ponteiro para estrutura console */ 

{ 


*/ 


/* Envia caracteres colocados no buffer em 'ramqueue” para a memória de tela, verifica a 


* nova posição do cursor, calcula a nova posição do cursor de hardware e a configura. 
*/ 

unsigned cur; 

tty t *tp = cons->C tty; 


/* Tem os caracteres em 'ramqueue” transferidos para a tela. */ 

if (cons->c rwords > 0) { 
mem vid copy(cons->c ramqueue, cons->c cur, cons->c rwords); 
cons->c rwords = 0; 


/* TTY gosta de conhecer a coluna corrente e se o eco bagunçou. */ 
tp->tty position = cons->c column; 
tp->tty reprint = TRUE; 

} 


/* Verifica e atualiza a posição do cursor. */ 
if (cons->c column < 0) cons->c_column = O; 
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if (cons->c column > scr width) cons->c column = scr width; 
if (cons->c row < 0) cons->c row = 0; 
if (cons->c row >= scr lines) cons->c row = scr lines - 1; 
cur = cons->Cc org + cons->c row * scr width + cons->c column; 
if (cur != cons->c cur) { 

if (cons == curcons) set 6845(CURSOR, cur); 

cons->c cur = cur; 


} 

} 

/* === ¥ 
i parse_escape * 
dD=======D>=2>=>>=>>=>>>=>>=>>=>=>>>>>=>>>>>>>>=>>>>>>>>>=>>>>>>>>=>>=>>=>=>=>>=>==>>===>==== * / 

PRIVATE void parse escape(cons, c) 

register console t *cons; /* ponteiro para estrutura console */ 

char c; /* próximo caractere na segiúência de escape */ 

{ 


/* As seguintes seqüências de escape ANSI são correntemente suportadas. 
* Se n e/ou m forem omitidas, o padrão delas será 1. 
* ESC [nA move n linhas para cima 
Ei ESC [nB move n linhas para baixo 
* ESC [nC move n espaços para a direita 
* ESC [nD move n espaços para a esquerda 
z ESC [m;nH" move o cursor para (m,n) 
* ESC [J limpa a tela a partir do cursor 
* ESC [K limpa a linha a partir do cursor 
z ESC [nL insere n linhas no cursor 
Ed ESC [nM exclui n linhas no cursor 
* ESC [nP exclui n cars no cursor 
* ESC [nQ insere n cars no cursor 
Ei ESC [nm ativa a exibição n (0=normal, 4=negrito, 5=intermitente, 7=inverso) 
* ESC M rola a tela para trás, se o cursor estiver na linha superior 


switch (cons->c esc state) { 
case 1: /* ESC visto */ 
cons->c esc intro "NO" 
cons->c esc parmp = bufend(cons->c esc parmv); 
do 1 


*--cons->c esc parmp = 0; 
} while (cons->c esc parmp > cons->c esc parmv); 
switch (c) { 
case "[": /* Introdutor de Segiiência de Controle */ 
cons->c esc intro = c; 


cons->c esc state = 2; 
break; 
case `M’: /* Índice Inverso */ 
do escape(cons, c); 
break; 
default: 

cons->c esc state = 0; 

} 

break; 

case 2: /* ESC [ visto */ 


if (c>="0" & c <= ’°9’°) { 
if (cons->c_esc_parmp < bufend(cons->c esc parmv)) 
*cons->c esc parmp = *cons->c_esc_parmp * 10 + (c-"0'); 
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16340 if (cons->c esc parmp < bufend(cons->c esc parmv)) 

16341 cons->c esc parmp++; 

16342 } else { 

16343 do escape(cons, c); 

16344 } 

16345 break; 

16346 } 

16347 } 

16349  /*===DD=DD>DDDDDDDDDDDDDDD0DDDDDDDDDD0DDDDDDDDDD0D0DDDDDDDDDD=D=>=>==>=>=>=>==>* 
16350 i do_escape # 
16351 PCDS e e 
16352 PRIVATE void do escape(cons, c) 

16353 register console t *cons; /* ponteiro para estrutura console */ 

16354 char c; /* próximo caractere na sequência de escape */ 
16355 { 

16356 int value, n; 

16357 unsigned src, dst, count; 

16358 int *parmp; 

16359 

16360 /* Algumas dessas coisas mexem na RAM de tela; portanto, é melhor atualizar */ 
16361 flush(cons); 

16362 

16363 if (cons->c esc intro == "10') É 

16364 /* Manipula uma seguência começando apenas com ESC */ 

16365 switch (c) { 

16366 case °M’: /* Índice Inverso */ 

16367 if (cons->c row == 0) { 

16368 scroll_screen(cons, SCROLL_DOWN) ; 

16369 } else { 

16370 cons->c_row--; 

16371 } 

16372 flush(cons); 

16373 break; 

16374 

16375 default: break; 

16376 3 

16377 } else 

16378 if (cons->c esc intro == ""[') { 

16379 /* Manipula uma seguência começando com ESC [ e parâmetros */ 
16380 value = cons->c esc parmv[0]; 

16381 switch (c) { 

16382 case ’A’: /* ESC [nA move n linhas para cima */ 

16383 n = (value == 0 ? 1 : value); 

16384 cons->c_row -= n; 

16385 flush(cons); 

16386 break; 

16387 

16388 case 'B”: /* ESC [nB move n linhas para baixo */ 
16389 n = (value == 0 ? 1: value); 

16390 cons->C row += n; 

16391 flush(cons); 

16392 break; 

16393 

16394 case 'C': /* ESC [nC move n espaços para a direita */ 
16395 n = (value == 0 ? 1: value); 

16396 cons->c column += n; 

16397 flush(cons); 

16398 break; 


16399 
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16400 
16401 
16402 
16403 
16404 
16405 
16406 
16407 
16408 
16409 
16410 
16411 
16412 
16413 
16414 
16415 
16416 
16417 
16418 
16419 
16420 
16421 
16422 
16423 
16424 
16425 
16426 
16427 
16428 
16429 
16430 
16431 
16432 
16433 
16434 
16435 
16436 
16437 
16438 
16439 
16440 
16441 
16442 
16443 
16444 
16445 
16446 
16447 
16448 
16449 
16450 
16451 
16452 
16453 
16454 
16455 
16456 
16457 
16458 
16459 


case 'D': /* ESC [nD move n espaços para a esquerda */ 
n = (value == 0 ? 1: value); 
cons->c column -= n; 
flush(cons); 
break; 
case °H’: /* ESC [m;nH" move o cursor para (m,n) */ 


cons->c row = cons->c esc parmv[0] - 1; 
cons->c column = cons->c esc parmv[1] - 1; 


flush(cons); 
break; 
case ’J’: /* ESC [sJ limpa a tela */ 
switch (value) { 
case O: /* Limpa do cursor até o final da tela */ 


count = scr size - (cons->c cur - cons->c org); 
dst = cons->c cur; 
break; 
case 1: /* Limpa do início da tela até o cursor */ 
count = cons->c cur - cons->c org; 
dst = cons->c org; 
break; 
case 2: /* Limpa a tela inteira */ 
count = scr size; 
dst = cons->c org; 


break; 
default: /* Não faz nada */ 
count = O; 


dst = cons->c org; 
} 
blank_color = cons->c_blank; 
mem_vid_copy(BLANK_MEM, dst, count); 


break; 
case °K’: /* ESC [sK limpa a linha a partir do cursor */ 
switch (value) { 
case 0: /* Limpa do cursor até o final da linha */ 
count = scr_width - cons->c_column; 
dst = cons->c cur; 
break; 
case 1: /* Limpa do início da linha até o cursor */ 
count = cons->c column; 
dst = cons->c cur - cons->c column; 
break; 
case 2: /* Limpa a linha inteira */ 
count = scr width; 
dst = cons->c cur - cons->c column; 
break; 
default: /* Não faz nada */ 
count = 0; 
dst = cons->c cur; 
} 


blank_color = cons->c_blank; 
mem_vid_copy(BLANK_MEM, dst, count); 
break; 


case ’L’: /* ESC [nL insere n linhas no cursor */ 
n = value; 
if 0< TD) n=l 
if (n > (scr lines - cons->c_row)) 
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16460 n = scr lines - cons->c row; 

16461 

16462 src = cons->c org + cons->c row * scr width; 

16463 dst = src + n * scr width; 

16464 count = (scr lines - cons->c row - n) * scr width; 
16465 vid vid copy(src, dst, count); 

16466 blank color = cons->c blank; 

16467 mem vid copy(BLANK MEM, src, n * scr width); 

16468 break; 

16469 

16470 case "M”: /* ESC [nM exclui n linhas no cursor */ 
16471 n = value; 

16472 if (n< 1)n= 1; 

16473 if (n > (scr_lines - cons->c_row)) 

16474 n = scr_lines - cons->c_row; 

16475 

16476 dst = cons->c_org + cons->c_row * scr_width; 

16477 src = dst + n * scr_width; 

16478 count = (scr lines - cons->c_row - n) * scr width; 
16479 vid vid copy(src, dst, count); 

16480 blank color = cons->c blank; 

16481 mem vid copy(BLANK MEM, dst + count, n * scr width); 
16482 break; 

16483 

16484 case "Q”: /* ESC [nQ insere n cars no cursor */ 
16485 n = value; 

16486 if (n < 1) ñ= 1; 

16487 if (n > (scr width - cons->c column)) 

16488 n = scr width - cons->c column; 

16489 

16490 src = cons->c cur; 

16491 dst = src + n; 

16492 count = scr_width - cons->c_column - n; 

16493 vid_vid_copy(src, dst, count); 

16494 blank_color = cons->c_blank; 

16495 mem vid copy(BLANK MEM, src, n); 

16496 break; 

16497 

16498 case °P’: /* ESC [nP exclui n cars no cursor */ 
16499 n = value; 

16500 if (n< 1) n= 1; 

16501 if (n > (scr width - cons->c column)) 

16502 n = scr width - cons->c column; 

16503 

16504 dst = cons->c cur; 

16505 src = dst + n; 

16506 count = scr_width - cons->c_column - n; 

16507 vid_vid_copy(src, dst, count); 

16508 blank_color = cons->c_blank; 

16509 mem_vid_copy(BLANK_MEM, dst + count, n); 

16510 break; 

16511 

16512 case 'm”: /* ESC [nm ativa exibição de n */ 
16513 for (parmp = cons->c_esc_parmv; parmp <= cons->c_esc_parmp 
16514 && parmp < bufend(cons->c_esc_parmv); parmp++) { 
16515 if (cons->c_reverse) { 

16516 /* Destroca cores fg e bg */ 

16517 cons->c_attr = ((cons->c_attr & 0x7000) >> 4) | 
16518 ((cons->c attr & 0x0700) << 4) | 


16519 ((cons->c attr & 0x8800)); 
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16520 
16521 
16522 
16523 
16524 
16525 
16526 
16527 
16528 
16529 
16530 
16531 
16532 
16533 
16534 
16535 
16536 
16537 
16538 
16539 
16540 
16541 
16542 
16543 
16544 
16545 
16546 
16547 
16548 
16549 
16550 
16551 
16552 
16553 
16554 
16555 
16556 
16557 
16558 
16559 
16560 
16561 
16562 
16563 
16564 
16565 
16566 
16567 
16568 
16569 
16570 
16571 
16572 
16573 
16574 
16575 
16576 
16577 
16578 
16579 


} 
switch (n = *parmp) { 
case O: /* NORMAL */ 
cons->c attr = cons->c blank = BLANK COLOR; 
cons->c reverse = FALSE; 
break; 
case 1: /* NEGRITO */ 
/* Configura o bit de intensidade */ 
cons->c attr |= 0x0800; 
break; 
case 4: /* SUBLINHADO */ 
if (color) { 
/* Muda branco para ciano, isto é vermelho fraco 
*/ 
cons->c_attr = (cons->c_attr & 0xBBFF); 
} else { 
/* Configura atributo de sublinhado */ 
cons->c_attr = (cons->c_attr & 0x99FF); 
} 
break; 
case 5: /* INTERMITENTE */ 
/* Configura o bit de intermitência */ 
cons->c_attr |= 0x8000; 
break; 
case 7: /* INVERSO */ 
cons->c_reverse = TRUE; 
break; 
default: /* COLORIDO */ 
if (n == 39) ñ = 37; /* configura a cor padrão */ 
if (n == 49) n = 40; 
If (!color) { 
/* Não bagunça uma tela monocromática */ 
} else 
if G0 <= n & n <= 37) { 
/* Cor de primeiro plano */ 
cons->c_attr = 
(cons->c_attr & OxF8FF) 
(ansi colors[(n - 30)] << 8); 
cons->c blank = 
(cons->c blank & 0xF8FF) 
(ansi colors[(n - 30)] << 8); 
+ else 
if (40 <= n & n <= 47) { 
/* Cor de segundo plano */ 
cons->c_attr = 
(cons->c_attr & 0x8FFF) 
(ansi_colors[(n - 40)] << 12); 
cons->c_blank = 
(cons->c blank & 0x8FFF) 
(ansi colors[(n - 40)] << 12); 
} 
} 


if (cons->c reverse) { 
/* Troca as cores fg e bg */ 
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16580 cons->c attr = ((cons->c attr & 0x7000) >> 4) | 
16581 ((cons->c attr & 0x0700) << 4) | 
16582 ((cons->c attr & 0x8800)); 

16583 } 

16584 J 

16585 break; 

16586 } 

16587 } 

16588 cons->c_esc_state = 0; 

16589 + 


16591 /*============== 
16592 3 á 
16593 
16594 PRIVATE void set t_6845(reg, val) 

16595 int reg; /* qual par de registradores vai configurar */ 
16596 unsigned val; /* valor de 16 bits para configurar */ 

16597 { 

16598 /* Configura umpar de registradores dentro da 6845. 

16599 * Os registradores 12-13 informam a 6845 onde começar na ram de vídeo 

16600 * Os registradores 14-15 informam a 6845 onde colocar o cursor 

16601 */ 

16602 pvb pair t char out[4]; 


16603 pv set(char out [0], vid port + INDEX, reg); /* configura registrador de índice */ 
16604 pv set(char out[1], vid port + DATA, (val>>8) & BYTE); /* byte superior */ 
16605 pv set(char out[2], vid port + INDEX, reg + 1); /* novamente */ 
16606 pv set(char out[3], vid port + DATA, val&BYTE); /* byte inferior */ 
16607 sys voutb(char out, 4); /* realiza a saída real */ 
16608 + 

16610 /%==========>>=>"5>D=5D">000>D n 
16611 * get 6845 x 
16612 $ onnaa) 
16613 PRIVATE void get_6845(reg, val) 

16614 int reg; /* qual par de registradores vai configurar */ 
16615 unsigned *val; /* valor de 16 bits para configurar */ 

16616 { 


16617 char v1, v2; 

16618 /* Obtém um par de registradores dentro da 6845. */ 
16619 sys_outb(vid_port + INDEX, reg); 

16620 sys_inb(vid_port + DATA, &v1); 

16621 sys_outb(vid_port + INDEX, reg+1); 

16622 sys_inb(vid_port + DATA, &v2); 

16623 *val = (v1 << 8) | v2; 


16624 + 

16626 

16627 

16628 

16629 PRIVATE void beep() 

16630 1 

16631 /* Faz um bip soar no alto-falante (saída de CRTL-G). 
16632 * Esta rotina funciona ativando os bits 0 e 1 na porta B do chip 
16633 * 8255 que ativa o alto-falante. 

16634 */ 

16635 static timer_t tmr_stop_beep; 


16636 pvb pair t char_out[3]; 
16637 clock t now; 

16638 int port b val, s; 
16639 
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/* Busca o tempo corrente antecipadamente para evitar que o bip atrase. */ 
if ((s=getuptime(&now)) != OK) 

panic("TTY","Console couldn't get clock's uptime.", s); 
if (!beeping) 1 


/* Configura o canal de temporizador 2, onda quadrada, com a frequência dada. 


pv set(char out[0], TIMER MODE, 0xB6); 
pv set(char out[1], TIMER2, (BEEP FREQ >> 0) & BYTE); 
pv set(char out[2], TIMER2, (BEEP FREQ >> 8) & BYTE); 
if (sys voutb(char out, 3)==0K) 1 
if (sys inb(PORT B, &port b val)==0K && 
sys outb(PORT B, (port b val|3))==0K) 
beeping = TRUE; 


} 

} 

/* Adiciona um temporizador na lista. Possivelmente reprograma o alarme. */ 
tmrs_settimer(&tty_timers, &tmr_stop_beep, now+B_TIME, stop_beep, NULL); 
if (tty_timers->tmr_exp_time != tty next timeout) { 

tty_next_timeout = tty_timers->tmr_exp_time; 
if ((s=sys setalarm(tty next timeout, 1)) != OK) 
panic("TTY","Console couldn't set alarm.", s); 


PRIVATE void stop beep(tmrp) 
timer t *tmrp; 
{ 
/* Desliga o bip, desativando os bits O e 1 em PORT_B. */ 

int port_b_val; 

if (sys inb(PORT B, &port_b_val)==0K && 

sys outb(PORT B, (port b val & “3))==0K) 
beeping = FALSE; 


PUBLIC void scr init(tp) 

tty t *tp; 

{ 

/* Inicializa o driver de tela. */ 
console_t *cons; 
phys_bytes vid_base; 
ul6_t bios columns, bios_crtbase, bios_fontlines; 
u8_t bios_rows; 
int line; 
intos? 
static int vdu_initialized = 0; 
unsigned page_size; 


/* Associa console e TTY. */ 
line = tp - &tty_table[0]; 
if (line >= nr cons) return; 
cons = &cons table[line]; 
cons->c tty = tp; 

tp->tty priv = cons; 


/* Inicializa o driver de teclado. */ 


*/ 


808 SISTEMAS OPERACIONAIS 


16700 kb_init(tp); 


16701 

16702 /* Preenche os ganchos de função TTY. */ 
16703 tp->tty_devwrite = cons_write; 

16704 tp->tty_echo = cons_echo; 

16705 tp->tty_ioctl = cons_ioctl; 

16706 


16707 /* Obtém os parâmetros da BIOS que descrevem o VDU. */ 
16708 if (! vdu_initialized++) { 


16709 

16710 /* E quanto a verificação de erros? O que fazer em caso de falha??? */ 
16711 s=sys vircopy(SELF, BIOS SEG, (vir bytes) VDU SCREEN COLS ADDR, 
16712 SELF, D, (vir bytes) &bios columns, VDU SCREEN COLS SIZE); 
16713 s=sys vircopy(SELF, BIOS SEG, (vir bytes) VDU CRT BASE ADDR, 
16714 SELF, D, (vir bytes) &bios crtbase, VDU CRT BASE SIZE); 
16715 s=sys vircopy(SELF, BIOS SEG, (vir bytes) VDU SCREEN ROWS ADDR, 
16716 SELF, D, (vir bytes) &bios rows, VDU SCREEN ROWS SIZE); 
16717 s=sys vircopy(SELF, BIOS SEG, (vir bytes) VDU FONTLINES ADDR, 
16718 SELF, D, (vir bytes) &bios fontlines, VDU FONTLINES SIZE); 
16719 

16720 vid port = bios crtbase; 

16721 scr width = bios columns; 

16722 font lines = bios fontlines; 

16723 scr lines = machine.vdu ega ? bios rows+1 : 25; 

16724 

16725 if (color) -£ 

16726 vid base = COLOR BASE; 

16727 vid size = COLOR SIZE; 

16728 } else { 

16729 vid base = MONO BASE; 

16730 vid size = MONO SIZE; 

16731 

16732 if (machine.vdu ega) vid size = EGA SIZE; 

16733 wrap = ! machine.vdu ega; 

16734 

16735 s = sys segctl(&vid index, &vid seg, &vid off, vid base, vid size); 
16736 

16737 vid size >>= 1; /* contagem de palavras */ 

16738 vid mask = vid size - 1; 

16739 

16740 /* Tamanho da tela (número de caracteres exibidos.) */ 

16741 scr size = scr lines * scr width; 

16742 

16743 /* Pode haver tantos consoles quantos a memória de vídeo permitir. */ 
16744 nr cons = vid size / scr size; 

16745 if (nr cons > NR CONS) nr cons = NR CONS; 

16746 if (nr cons > 1) wrap = 0; 

16747 page size = vid size / nr cons; 

16748 

16749 

16750 cons->c start = line * page size; 

16751 cons->c limit = cons->c start + page size; 

16752 cons->c cur = cons->C org = cons->cC start; 

16753 cons->c attr = cons->c blank = BLANK COLOR; 

16754 

16755 if (line != 0) 1 

16756 /* Limpa os vtys que não são do console. */ 

16757 blank color = BLANK COLOR; 

16758 mem vid copy(BLANK MEM, cons->c start, scr size); 


16759 } else { 
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16760 
16761 
16762 
16763 
16764 
16765 
16766 
16767 
16768 
16769 
16770 


16772 
16773 
16774 
16775 
16776 
16777 
16778 
16779 


16781 
16782 
16783 
16784 
16785 
16786 
16787 
16788 
16789 
16790 
16791 
16792 
16793 
16794 
16795 
16796 
16797 
16798 
16799 
16800 
16801 
16802 
16803 
16804 
16805 
16806 
16807 
16808 
16809 
16810 
16811 
16812 
16813 
16814 
16815 
16816 
16817 
16818 


inti,n; 
/* Configura o cursor do console vty na parte inferior. c cur 
* é atualizada automaticamente, mais tarde. 
scroll screen(cons, SCROLL UP); 
cons->c row = scr lines - 1; 
cons->c column = 0; 
} 
select_console(0); 
cons_ioctl(tp, 0); 


F 

JESE 
ii kputc i 
X S==s= * / 

PUBLIC void kputc(c) 

int c; 

{ 

putk(c); 

} 

[Jie a >>. * 
* do new kmess * 
X Dm= * / 

PUBLIC void do new kmess (m) 

message *m; 

{ 

/* Notificação de uma nova mensagem de núcleo. */ 

struct kmessages kmess; /* estrutura kmessages */ 
static int prev next = 0; /* next anterior visto */ 
int size, next; 

int bytes; 

int r; 


/* Tenta obter uma cópia atualizada do buffer com mensagens de núcleo. */ 
sys getkmessages (&kmess) ; 


/* Imprime apenas a parte nova. Determina quantos bytes novos existem, com a 
* ajuda do índice 'next” corrente e anterior. Note que o buffer do 
* núcleo é circular. Isso funciona bem se menos de KMESS BUF SIZE bytes 
* forem dados novos; senão, perdemos % KMESS BUF SIZE aqui. 
* Verifica se o tamanho é positivo, o buffer também poderia ser esvaziado! 
*/ 
if (kmess.km_size > 0) { 
bytes = ((kmess.km_next + KMESS_BUF_SIZE) - prev_next) % KMESS_BUF_SIZE; 
r=prev_next; /* início em ‘previous’ antigo */ 
while (bytes > 0) { 
putk( kmess.km_buf[(r%KMESS_BUF_SIZE)] ); 


bytes --; 
r ++; 
} 
putk(0); /* termina para descarregar a saída */ 


} 


/* Quase pronto, armazena ’next’ para que possamos determinar qual parte do 


* buffer de mensagens do núcleo será impressa na próxima vez que uma notificação chegar. 


*/ 


prev_next = kmess.km_next; 
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16820  /*===================>=>==>>=>D="=D>=D="=>D=>=2=>=D=>>D="=0D=2>===2=>=2=="=>=2===>====>======== * 
16821 i do_diagnostics * 
16822 FEEDS DESSS SDS D=CEE DCE DEcESDesD sont / 
16823 PUBLIC void do diagnostics(m ptr) 

16824 message “m ptr; /* ponteiro para mensagem de requisição */ 
16825 { 


16826 /* Imprime uma string para um servidor. */ 
16827 char c; 

16828 vir bytes src; 

16829 int count; 

16830 int result = OK; 

16831 int proc nr = m ptr->DIAG PROC NR; 


16832 if (proc nr == SELF) proc nr = m ptr->m source; 

16833 

16834 src = (vir bytes) m ptr->DIAG PRINT BUF; 

16835 for (count = m ptr->DIAG BUF COUNT; count > 0; count--) { 

16836 if (sys vircopy(proc nr, D, src4+, SELF, D, (vir bytes) &c, 1) != OK) 1 
16837 result = EFAULT; 

16838 break; 

16839 } 

16840 putk(c); 

16841 } 

16842 putk(0); /* sempre termina, mesmo com EFAULT */ 

16843 m_ptr->m_type = result; 

16844 send(m_ptr->m_source, m_ptr); 

16845 + 

16847  /*====================================================== * 
16848 ii putk id 
16849 FOSSE SSSSSSSSSSSSSSSSSSESSSS SSD ESSES SSSSSES SDS SS o / 
16850 PRIVATE void putk(c) 

16851 int c; /* caractere to print */ 

16852 { 

16853 /* Esta rotina é usada pela versão de printf O vinculada ao 

16854 * driver TTY. A que está na biblioteca envia uma mensagem para o FS, que não é 
16855 * o que é necessário para imprimir dentro do TTY. Esta versão apenas enfileira o 
16856 * caractere e inicia a saída. 

16857 */ 

16858 if (cl=0)1 

16859 if (Cc == "n" putkCAr'D; 

16860 out char(&cons table[0], Cint) c); 

16861 } else { 

16862 flush(&cons_table[0]); 

16863 } 

16864 + 

16866 

16867 

16868 

16869 PUBLIC void toggle scroi1QO 

16870 { 

16871 /* Alterna entre rolagem por hardware e por software. */ 

16872 

16873 cons org0(); 

16874 softscroll = Isoftscroll; 

16875 printf("%sware scrolling enabled. An”, softscroll ? "Soft" : "Hard"); 


16876 } 
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16878 — /%========>=========>==>===>==>===>>==>>=>>==>>==>>==>>=>>==>>==>>>=>==>>"==>======—= * 
16879 E cons stop * 
16880 X EDDD==D=D=D>=>>=>>=>>>>>=>=>=>>=>=>>=>>=>=>=>=>=>=>>>>>=>>=>=>>>>=>>>>>=>>=>>=>=>=>=>>=>=>=>=>===> * / 
16881 PUBLIC void cons stop() 

16882 1 


16883 /* Prepara para parar ou reinicializar. */ 

16884 cons org0(); 

16885 softscroll = 1; 

16886 select console(0); 

16887 cons table[0].c attr = cons table[0].c blank = BLANK COLOR; 


16888 + 

16890 — /Z====D==D=D=D=D=>D==>=D=>D=2=D2==2D=>D=D=D2>2==2=>=D==2=2=02==>=>="=02====>=>==========— * 
16891 Ei cons org0 * 
16892 EDD=D==>=D=D>=>>=>>=>>>>=>=>=>=>>=>>>>>>=>=>=>>=>=>>>>=>=>>=>>=>>>>=>>>=>>=>>=>>=>>=>>=>>=>=>=>=>===> * / 
16893 PRIVATE void cons org0() 

16894 1 


16895 /* Rola a memória de vídeo para trás, para colocar a origem em 0. */ 
16896 int cons line; 


16897 console t *cons; 

16898 unsigned n; 

16899 

16900 for (cons line = 0; cons line < nr cons; cons line++) { 

16901 cons = &cons table[cons line]; 

16902 while (cons->c org > cons->c start) { 

16903 n = vid size - scr size; /* quantidade de memória não utilizada */ 
16904 if (n > cons->c org - cons->c start) 

16905 n = cons->c org - cons->c start; 

16906 vid vid copy(cons->c org, cons->c org - n, scr size); 

16907 cons->c org -= n; 

16908 3 

16909 flush(cons); 

16910 

16911 select console(ccurrent); 

16912 3 

16914 /*== a 
16915 * select console * 
16916 oD=D===D======================>============================================ * / 
16917 PUBLIC void select console(int cons Tine) 

16918 { 


16919 /* Configura o console corrente com o número de console "cons line”. */ 
16920 


16921 if (cons line < O || cons line >= nr cons) return; 
16922 ccurrent = cons line; 
16923 curcons = &cons table[cons line]; 


16924 set 6845(VID ORG, curcons->c org); 
16925 set 6845(CURSOR, curcons->c cur); 


16926 + 

16928 — /Z=======================>==>=>=>>=>=>=>==>=>=>=>>=>>=>=>=>==>=>=>>>>>>=>=>>=>=>=>>=>=>====>===>"* 
16929 * con Toadfont * 
16930 [SED ES CSS SA O e A) 


16931 PUBLIC int con loadfont(m) 
16932 message *m; 


16933 { 

16934 /* Carrega uma fonte no adaptador EGA ou VGA. */ 
16935 int result; 

16936 static struct sequence seg1l[7] = 1 


16937 { GA SEQUENCER INDEX, 0x00, 0x01 3, 
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{ GA SEQUENCER INDEX, 0x02, 0x04 3, 
{ GA SEQUENCER INDEX, 0x04, 0x07 3, 
{ GA SEQUENCER INDEX, 0x00, 0x03 3, 
{ GA GRAPHICS INDEX, 0x04, 0x02 3, 

{ GA GRAPHICS INDEX, 0x05, 0x00 3, 

{ GA GRAPHICS INDEX, 0x06, 0x00 3, 

3; 

static struct sequence seg2[7] = 1 

GA SEQUENCER INDEX, 0x00, 0x01 }, 
GA SEQUENCER INDEX, 0x02, 0x03 }, 
GA SEQUENCER INDEX, 0x04, 0x03 }, 
GA SEQUENCER INDEX, 0x00, 0x03 }, 
GA GRAPHICS INDEX, 0x04, 0x00 3, 

GA GRAPHICS INDEX, 0x05, 0x10 3, 

GA GRAPHICS INDEX, 0x06, O 3 


mman 


}; 
seq2[6].value= color ? 0x0E : 0x0A; 


if (!machine.vdu_ega) return(ENOTTY); 
result = ga program(seql); /* apresenta a memória de fonte */ 


result = sys physcopy(m->PROC NR, D, (vir bytes) m->ADDRESS, 
NONE, PHYS SEG, Cphys bytes) GA VIDEO ADDRESS, C(phys bytes)GA FONT SIZE): 


result = ga program(seg2); /* restaura */ 


return(result); 


PRIVATE int ga program(seqg) 
struct sequence *seq; 
{ 
pvb pair t char_out[14]; 
int i; 
for Ci=0; i<7; i++) { 
pv set(char out[2*i], seq->index, seq->port); 
pv set(char out[2*i+1], seq->index+1, seq->value); 
seg++; 
} 


return sys_voutb(char_out, 14); 


PRIVATE int cons_ioctl(tp, try) 
tty t “tp; 

int try; 

{ 


/* Configura as dimensões da tela. */ 


tp->tty winsize.ws row= scr lines; 

tp->tty winsize.ws col= scr width; 

tp->tty winsize.ws xpixel= scr width * 8; 

tp->tty winsize.ws ypixel= scr lines * font lines; 
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AAA ++ 


servers/pm/pm.h 


HEHEHEHEH HEHH HHHH HHHH H+H HH HHHH HH HHHH HHHH HHHH H+H HHHH HHHH HHHH HH+H+HH+H+H+H+H+H+H 


17000 
17001 
17002 
17003 
17004 
17005 
17006 
17007 
17008 
17009 
17010 
17011 
17012 
17013 
17014 
17015 
17016 
17017 
17018 
17019 
17020 
17021 
17022 
17023 
17024 
17025 


/* Este é o cabeçalho mestre do PM. Ele inclui alguns 


* e define as principais constantes. 


#define _ 
#define | 
#define _ 


/* O que 
#include 
#include 
#include 
#include 
#include 


#include 
#include 
#include 
#include 


#include 
#include 


#include 
#include 
#include 
#include 


POSIX_SOURCE 
MINIX 
SYSTEM 


segue é básico, todos os arquivos 


<minix/config.h> 
<ansi.h> 
<sys/types.h> 
<minix/const.h> 
<minix/type.h> 


<fecntl.h> 
<unistd.h> 
<minix/syslib.h> 
<minix/sysutil.h> 


<limits.h> 
<errno.h> 


"const.h” 
“type.h" 
"proto.h" 
"glo.h” 


/* diz aos 
/* diz aos 
/* diz aos 


cabeçalhos 
cabeçalhos 
cabeçalhos 


outros arquivos 


para incluírem material do POSIX */ 
para incluírem material do MINIX */ 
que este é o núcleo */ 


*.c os obtêm automaticamente. */ 


/* DEVE ser o primeiro */ 
/* DEVE ser o segundo */ 


HEHEHEHEHE HHHH HHHH HHHH H+H HH HH HHHH H+ HHHH HHHH ++ 


servers/pm/const.h 


HEHEHEHEH HEHH HHHH HHHH H+H H+ HH HH HH HHHH H+H HH HH H+H HHHH HHH H+ HHH HHHH HH+H+H+H+H+H+H+H+H+ 


17100 
17101 
17102 
17103 
17104 
17105 
17106 
17107 
17108 
17109 
17110 
17111 


/* Constantes usadas pelo Gerenciador de Processos. 


*/ 


#define NO MEM ((phys_clicks) 0) /* retornado por alloc mem() com mem é acima */ 


tdefine NR PIDS 


tdefine PM PID 
tdefine INIT PID 


30000 


/* as ids de processo variam de O a NR PIDS-1. 
* (constante mágica: alguns aplicativos antigos usam 
* "short", em vez de pid t.) 


sy 


/* número da id de processo do PM */ 
/* número da id de processo de INIT */ 
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HEHHEHE HHHH RD O HHHH HHHH HHHH HHHH HHHH O O O O O O HHHH O SR E OR DO ED OD RD OR RE 
servers/pm/type.h 
ED o o RA O HHHH HHHH HHHH HEHEHHE HHHH HHHH O O O O O O O OD O O ORA E OR DD DD RD RD RE 


17200 /* Se houvesse quaisquer definições de tipo locais para o Gerenciador de Processos, elas 


17201 * ficariam aqui. Este arquivo foi incluído apenas por simetria com o núcleo e com o Sistema 
17202 * de Arquivos, que têm algumas definições de tipo locais. 

17203 */ 

17204 


DO spa Do O o O O O RO DO HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH HHHH H+ O DA DO O O O 
servers/pm/proto.h 
DO sa Do O O a O +H O RO DO DO DO HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O DO O O O O 


17300 /* Prototypes de função. */ 
17301 

17302 struct mproc; 

17303 struct stat; 

17304 struct mem map; 

17305 struct memory; 


17306 

17307 #include <timers.h> 

17308 

17309 /* alloc.c */ 

17310 | PROTOTYPE( phys clicks alloc mem, (phys clicks clicks) DD; 
17311 | PROTOTYPE( void free mem, (phys clicks base, phys clicks clicks) J; 
17312 | PROTOTYPE( void mem_init, (struct memory *chunks, phys clicks *free) J; 
17313 #define swap inQO ((void)0) 

17314 #define swap inqueue(rmp) ((void)0) 

17315 


17316 /* break.c */ 

17317 |. PROTOTYPE( int adjust, (struct mproc *rmp, 
17318 vir clicks data clicks, vir bytes sp) 35 
17319 | PROTOTYPE( int do brk, (void) ) 
17320 _PROTOTYPEÇ int size ok, (int file type, vir clicks tc, vir clicks dc, 
17321 vir clicks sc, vir clicks dvir, vir clicks s vir) ); 
17322 

17323 /* devio.c */ 

17324 | PROTOTYPE( int do dev io, (void) ); 

17325  _PROTOTYPE( int do dev io, (void) ); 


17326 

17327 /* dmp.c */ 

17328 | PROTOTYPE( int do fkey pressed, (void) Jj 
17329 

17330 /* exec.c */ 

17331 | PROTOTYPE( int do_exec, (void) Jë 
17332 _PROTOTYPE(Ç void rw seg, (int rw, int fd, int proc, int seg, 

17333 phys bytes seg bytes) J 
17334 | PROTOTYPE( struct mproc *find_share, (struct mproc *mp_ign, Ino t ino, 
17335 Dev_t dev, time_t ctime) js 
17336 


17337 /* forkexit.c */ 

17338  _PROTOTYPE(Ç( int do_fork, (void) ) 
17339 | PROTOTYPE( int do pm exit, (void) J}; 
17340 _PROTOTYPEÇ int do waitpid, (void) ) 
17341 | PROTOTYPE( void pm exit, (struct mproc *rmp, int exit status) ) 
17342 

17343 /* getset.c */ 

17344 | PROTOTYPE( int do_getset, (void) J; 
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17345 
17346 
17347 
17348 
17349 
17350 
17351 
17352 
17353 
17354 
17355 
17356 
17357 
17358 
17359 
17360 
17361 
17362 
17363 
17364 
17365 
17366 
17367 
17368 
17369 
17370 
17371 
17372 
17373 
17374 
17375 
17376 
17377 
17378 
17379 
17380 
17381 
17382 
17383 
17384 
17385 
17386 
17387 
17388 
17389 
17390 
17391 
17392 
17393 
17394 
17395 
17396 
17397 
17398 
17399 
17400 


/* main.c */ 
- PROTOTYPE( int main, (void) 

/* misc.c */ 

- PROTOTYPE( int do reboot, (void) 

- PROTOTYPE( int do getsysinfo, (void) 

- PROTOTYPE( int do getprocnr, (void) 

- PROTOTYPE( int do svrctl, (void) 

- PROTOTYPE( int do allocmem, (void) 

- PROTOTYPE( int do freemem, (void) 

- PROTOTYPE( int do getsetpriority, (void) 


- PROTOTYPE( void setreply, (int proc nr, int result) 


/* signal.c */ 

- PROTOTYPE( int do alarm, (void) 

- PROTOTYPE( int do kill, (void) 

- PROTOTYPE( int ksig pending, (void) 

- PROTOTYPE( int do pause, (void) 

- PROTOTYPE( int set alarm, (int proc nr, int sec) 

- PROTOTYPE( int check sig, (Cpid t proc id, int signo) 

- PROTOTYPE( void sig proc, (struct mproc *rmp, int sig nr) 

- PROTOTYPE( int do sigaction, (void) 

- PROTOTYPE( int do sigpending, (void) 

- PROTOTYPE( int do sigprocmask, (void) 

- PROTOTYPE( int do sigreturn, (void) 

- PROTOTYPE( int do sigsuspend, (void) 

- PROTOTYPE( void check pending, (struct mproc *rmp) 

/* time.c */ 

- PROTOTYPE( int do stime, (void) 

- PROTOTYPE( int do time, (void) 

- PROTOTYPE( int do times, (void) 

- PROTOTYPE( int do gettimeofday, (void) 

/* timers.c */ 

- PROTOTYPE( void pm set timer, (timer t *tp, int delta, 
tmr func t watchdog, int arg)); 

- PROTOTYPE( void pm expire timers, (clock t now)); 

- PROTOTYPE( void pm cancel timer, (timer t *tp)); 


/* trace.c */ 
- PROTOTYPE( int do trace, (void) 
- PROTOTYPE( void stop proc, (struct mproc *rmp, int sig nr) 


/* utility.c */ 

- PROTOTYPE( pid t get free pid, (void) 

- PROTOTYPE( int allowed, (char *name buf, struct stat *s buf, int mask) 
- PROTOTYPE( int no sys, (void) 

- PROTOTYPE( void panic, (char “who, char *mess, int num) 

- PROTOTYPE( void tell fs, (int what, int p1, int p2, int p3) 

- PROTOTYPE( int get stack ptr, (int proc nr, vir bytes *sp) 
-PROTOTYPE( int get mem map, (int proc nr, struct mem map *mem map) 

- PROTOTYPE( char *find param, (const char *key)); 

- PROTOTYPE( int proc from pid, (pid_t p)); 
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17500 /* EXTERN deve ser extern, exceto em table.c */ 
17501 #ifdef _TABLE 

17502 #undef EXTERN 

17503 #define EXTERN 

17504 #endif 


17505 

17506 /* Variáveis globais. */ 

17507 EXTERN struct mproc “mp; /* ptr para entrada 'mproc” do processo corrente */ 
17508 EXTERN int procs in use; /* quantos processos estão marcados como IN USE */ 

17509 EXTERN char monitor params[128*sizeof(char *)]; /* parâm. do monitor de inicialização */ 
17510 EXTERN struct kinfo kinfo; /* informações do núcleo */ 

17511 

17512 /* Os parâmetros da chamada são mantidos aqui. */ 

17513 EXTERN message m in; /* a própria mensagem recebida é mantida aqui. */ 

17514 EXTERN int who; /* número do processo que fez a chamada */ 

17515 EXTERN int call nr; /* número da chamada de sistema */ 

17516 

17517 extern PROTOTYPE (int (“call vec[]), (void) ); /* rot. de tratamento de chamada de sistema */ 
17518 extern char core name[]; /* nome de arquivo onde core dump são geradas */ 

17519 EXTERN sigset t core sset; /* quais sinais causam imagens do núcleo */ 

17520 EXTERN sigset t ign sset; /* quais sinais são ignorados por padrão */ 

17521 


HHHEHEHHHHHHH +EH HHH HHHH HHHH HHHH HHH HHHH H+H HH HHHH HHHH H+ O O O DO O OD O O 
servers/pm/mproc.h 
HHHH O O O O O HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO OO O O O 


17600 /* Esta tabela tem uma entrada por processo. Ela contém todas as informações de 


17601 * gerenciamento de processo para cada processo. Dentre outras coisas, ela define os 
17602 * segmentos de texto, dados e pilha, uids e gids, e vários flags. O núcleo e os sistemas 
17603 * de arquivos têm tabelas que também são indexadas pelo processo, com o conteúdo 
17604 * das entradas correspondentes se referindo ao mesmo processo em todos os três. 
17605 */ 

17606 #include <timers.h> 

17607 

17608 EXTERN struct mproc 1 

17609 struct mem map mp seg[NR LOCAL SEGS]; /* aponta para texto, dados, pilha */ 

17610 char mp exitstatus; /* armazenamento para status quando o processo sai */ 
17611 char mp sigstatus; /* armazenamento para sinal & para processos eliminados */ 
17612 pid tmp pid; /* id de processo */ 

17613 pid t mp procgrp; /* pid de grupo de processo (usado para sinais) */ 
17614 pid tmp wpid; /* pid pelo qual este processo está esperando */ 
17615 int mp parent; /* índice do processo pai */ 

17616 

17617 /* Tempos de usuário filho e sistema. Contabilidade feita na saída do filho. */ 
17618 clock t mp child utime; /* tempo de usuário acumulativo dos filhos */ 

17619 clock t mp child stime; /* tempo de sistema acumulativo dos filhos */ 

17620 

17621 /* Uids e gids reais e efetivas. */ 

17622 uid t mp realuid; /* uid real do processo */ 

17623 uid t mp effuid; /* uid efetiva do processo */ 


17624 gid t mp realgid; /* gid real do processo */ 
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17625 gid t mp effgid; /* gid efetiva do processo */ 

17626 

17627 /* Identificação de arquivo para compartilhamento. */ 

17628 ino t mp ino; /* número do i-node do arquivo */ 

17629 dev t mp dev; /* número do dispositivo do sistema de arquivos */ 
17630 time t mp ctime; /* tempo do i-node alterado */ 

17631 

17632 /* Informações de tratamento de sinal. */ 

17633 sigset t mp ignore; /* 1: captura sinal; O: não captura */ 

17634 sigset t mp catch; /* 1: ignora sinal; O: não ignora */ 

17635 sigset t mp sig2mess; /* 1 significa transformar em mensagem de notificação */ 
17636 sigset t mp sigmask; /* sinais a serem bloqueados */ 

17637 sigset t mp sigmask2; /* cópia salva de mp sigmask */ 

17638 sigset t mp sigpending; /* sinais pendentes a serem manipulados */ 

17639 struct sigaction mp sigact[ NSIG + 1]; /* como em sigaction(2) */ 

17640 vir bytes mp sigreturn; /* endereço da função | sigreturn da biblioteca C */ 
17641 struct timer mp timer; /* temporizador cão de guarda de alarm(2) */ 

17642 

17643 /* Compatibilidade com versões anteriores para sinais. */ 

17644 sighandler t mp func; /* todos os sinais para uma única função de usuário */ 
17645 

17646 unsigned mp flags; /* bits de flag */ 

17647 vir bytes mp procargs; /* ptr para argumentos de pilha iniciais do processo */ 
17648 struct mproc “mp swapq; /* fila de processos esperando para irem para a memória */ 
17649 message mp reply; /* mensagem de resposta a ser enviada para um */ 

17650 

17651 /* Prioridade de escalonamento. */ 

17652 signed int mp nice; /* nice é PRIO MIN..PRIO MAX, o padrão é 0. */ 

17653 


17654 char mp name[PROC NAME LEN]; /* nome do processo */ 
17655 } mproc[NR PROCS]; 


17656 

17657 /* Valores de flag */ 

17658 define IN USE 0x001 /* ativado quando a entrada 'mproc” está em uso */ 

17659  &define WAITING 0x002 /* ativado pela chamada de sistema WAIT */ 

17660 define ZOMBIE 0x004 /* ativado por EXIT, desativado por WAIT */ 

17661 define PAUSED 0x008 /* ativado pela chamada de sistema PAUSE */ 

17662 #define ALARM ON 0x010 /* ativado quando o temporizador SIGALRM é iniciado */ 
17663 #define SEPARATE 0x020 /* ativado se o arquivo tem espaço I & D separado */ 
17664 #define TRACED 0x040 /* ativado se o processo vai ser rastreado */ 

17665 #define STOPPED 0x080 /* ativado se o processo parou de rastrear */ 

17666 #define SIGSUSPENDED 0x100 /* ativado pela chamada de sistema SIGSUSPEND */ 

17667 #define REPLY 0x200 /* ativado se uma mensagem de resposta estiver pendente */ 
17668 #define ONSWAP 0x400 /* ativado se o seg. de dados for transferido para disco */ 
17669 define SWAPIN 0x800 /* ativado se estiver na fila "swap this in" */ 

17670 &define DONT SWAP 0x1000 /* nunca faz swap neste processo */ 

17671 &define PRIV PROC 0x2000 /* processo de sistema, privilégios especiais */ 

17672 

17673 #define NIL MPROC ((struct mproc *) 0) 

17674 


DO ssa Do O o a O OD RO HHHH HHHH HHHH HHHH HH H+H HH HHHH O DD H+ O O O O OO O O 
servers/pm/param.h 
AA RRAAARRARPRARRRRARAAA+++ 


17700 /* Os nomes a seguir são sinônimos para as variáveis na mensagem de entrada. */ 
17701 #define addr mi pl 
17702 &define exec name ml pl 
17703 &define exec Ten mi il 
17704 #define func m6 f1 


818 


SISTEMAS OPERACIONAIS 


17705 #define grp id mi il 
17706  &define namelen ml i2 
17707 #define pid miit 
17708 #define procnr mi il 
17709 &define seconds mi il 
17710 #define sig m6 il 
17711 #define stack bytes ml i2 
17712 #define stack ptr mi p2 
17713 &define status mi il 
17714 define usr id mi il 
17715 #define request m2 12 
17716 #define taddr m2 11 
17717 define data m2 12 
17718 #define sig nr ml i2 
17719 #define sig nsa ml pl 
17720 #define sig osa mi p2 
17721 &define sig ret ml p3 
17722 #define sig set m2 11 
17723 #define sig how m2 il 
17724 #define sig flags m2 12 
17725 #define sig context m2 pl 
17726 &define info what mi il 
17727 #define info where ml pl 
17728 #define reboot flag mi il 
17729 &define reboot code mi pl 
17730 &define reboot strlen mi i2 
17731 #define svrctl req m2 11 
17732 #define svrctl argp m2 pl 
17733 &define stime m2 11 
17734 &define memsize m4 11 
17735 &define membase m4 12 
17736 

17737 /* Os nomes a seguir são sinônimos para as variáveis na mensagem de resposta. */ 
17738 #define reply res m type 
17739 #define reply res2 m2 il 
17740 #define reply ptr m2 pl 
17741 #define reply mask m2 11 
17742 #define reply trace m2 12 
17743 #define reply time m2 11 
17744 #define reply utime m2 12 
17745 #define reply ti m4 11 
17746 #define reply t2 m4 12 
17747 #define reply t3 m4 13 
17748 #define reply t4 m4 14 
17749 #define reply t5 m4 15 
17750 

17751 /* Os nomes a seguir são usados para informar o FS sobre certos eventos. */ 
17752 4define tell fs argl mi il 
17753 &define tell fs arg? ml i2 
17754 #define tell fs arg3 mi 53 


17755 
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HHHEHHHHHHHHH HHHH H+ HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O O DO DO O O O 
servers/pm/table.c 
DO sa Do O o a DS +H HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O SD DO OO O O O 


17800 
17801 
17802 
17803 
17804 
17805 
17806 
17807 
17808 
17809 
17810 
17811 
17812 
17813 
17814 
17815 
17816 
17817 
17818 
17819 
17820 
17821 
17822 
17823 
17824 
17825 
17826 
17827 
17828 
17829 
17830 
17831 
17832 
17833 
17834 
17835 
17836 
17837 
17838 
17839 
17840 
17841 
17842 
17843 
17844 
17845 
17846 
17847 
17848 
17849 
17850 
17851 
17852 
17853 
17854 


/* Este arquivo contém a tabela usada para fazer o mapeamento de números de chamada 


* de sistema nas rotinas que as executam. 


EA 


gdefine TABLE 


tinclude 
tinclude 
tinclude 
tinclude 
tinclude 


"pm.h" 


<minix/callnr.h> 


<signal.h> 
"mproc.h" 
"param.h" 


/* Miscelânea */ 
char core_name[] = "core"; 


/* 


nome de arquivo onde os core dump são gerados * 


_PROTOTYPE (int (*call_vec[NCALLS]), (void) )= { 


no_sys, 
do_pm_exit, 
do_fork, 
no_sys, 
no_sys, 
no_sys, 
no_sys, 
do_waitpid, 
no_sys, 
no_sys, 
no_sys, 
do_waitpid, 
no_sys, 
do_time, 
no_sys, 
no_sys, 
no_sys, 
do_brk, 
no_sys, 
no_sys, 
do_getset, 
no_sys, 
no_sys, 
do_getset, 
do_getset, 
do_stime, 
do_trace, 
do_alarm, 
no_sys, 
do_pause, 
no_sys, 
no_sys, 
no_sys, 
no_sys, 
no_sys, 
no_sys, 
no_sys, 

do kill, 

no sys, 


/* 


DONOS UBwNnNHO 


não usado */ 


exit */ 
fork */ 
read */ 
write */ 
open */ 
close */ 
wait */ 
creat ki 
link */ 
unlink */ 
waitpid */ 
chdir */ 
time */ 
mknod */ 
chmod */ 
chown */ 
break */ 
stat */ 
Tseek */ 
getpid */ 
mount */ 
umount */ 
setuid */ 
getuid */ 
stime */ 
ptrace */ 
alarm */ 
fstat */ 
pause */ 
utime */ 
Cstty) */ 
Cgtty) */ 
access */ 
(nice) */ 
(ftime) */ 
sync */ 
kill 3y 
= rename */ 
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17855 
17856 
17857 
17858 
17859 
17860 
17861 
17862 
17863 
17864 
17865 
17866 
17867 
17868 
17869 
17870 
17871 
17872 
17873 
17874 
17875 
17876 
17877 
17878 
17879 
17880 
17881 
17882 
17883 
17884 
17885 
17886 
17887 
17888 
17889 
17890 
17891 
17892 
17893 
17894 
17895 
17896 
17897 
17898 
17899 
17900 
17901 
17902 
17903 
17904 
17905 
17906 
17907 
17908 
17909 
17910 
17911 


Js 


/* Isso não deve falhar com "array size is negative": 
extern int dummy[sizeof(call vec) == NCALLS * sizeof(call vec[0]) ? 1: 


no sys, 
no sys, 
no sys, 
no sys, 
do times, 
no sys, 
no sys, 
do getset, 
do getset, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
do exec, 
no sys, 
no sys, 
do getset, 
do getset, 


no sys, 
no sys, 

no sys, 

no sys, 

no sys, 

no sys, 

no sys, 

do sigaction, 
do sigsuspend, 
do sigpending, 
do sigprocmask, 
do sigreturn, 
do reboot, 

do svrctl, 


no sys, 
do getsysinfo, 
do getprocnr, 
no sys, 

no sys, 

do allocmem, 
do freemem, 

no sys, 

no sys, 

no sys, 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


do getsetpriority, 
do getsetpriority, 


do time, 


/* 


= mkdir */ 


rmdir */ 
dup Ref 
pipe 6 
times */ 
(prof) */ 
não usado*/ 
setgid */ 
getgid */ 
(signal)*/ 


não usado */ 
não usado */ 


(acct) */ 
(phys) */ 
Clock) */ 
ioctl */ 
fcnt] */ 
(mpx) */ 


não usado */ 
não usado */ 
execve */ 
umask */ 
chroot */ 
setsid */ 
getpgrp */ 


não usado */ 
UNPAUSE */ 
não usado */ 
REVIVE */ 
TASK_REPLY */ 
não usado */ 
não usado */ 
sigaction */ 
sigsuspend */ 
sigpending */ 
sigprocmask */ 
sigreturn */ 
reboot */ 


= svret] */ 


não usado */ 
getsysinfo */ 
getprocnr */ 
não usado */ 
fstatfs */ 
memalloc */ 
memfree */ 
select */ 
fchdir */ 


= fsync */ 
/* 88 = getpriority */ 
/* 89 = setpriority */ 
90 = gettimeofday */ 


*/ 


-1]; 


Apêndice B e O Cóbigo-FONTE DO MINIX 821 


HHHHHHHH+H H+ HH HHHH HHHH HH HH HH HHHH H+ HHHH HHHH HHHH H+H HHHH H+ HH H+ HH HH+H+HH+H+H+H+H+H+H 
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HEHEHEHEH HEHH HHHH H+H HH H+H H+ HHHH HH HHHH H+H HH HHHH H+H HHHH HHH HH+HH+HHH+HH+H+HH+H+H+H+H+H+ 


18000 
18001 
18002 
18003 
18004 
18005 
18006 
18007 
18008 
18009 
18010 
18011 
18012 
18013 
18014 
18015 
18016 
18017 
18018 
18019 
18020 
18021 
18022 
18023 
18024 
18025 
18026 
18027 
18028 
18029 
18030 
18031 
18032 
18033 
18034 
18035 
18036 
18037 
18038 
18039 
18040 
18041 
18042 
18043 
18044 
18045 
18046 
18047 
18048 
18049 
18050 
18051 
18052 
18053 
18054 


/* Este arquivo contém o programa principal do gerenciador de processos e algumas 
* rotinas relacionadas. Quando o MINIX inicia, o núcleo é executado por algum tempo, 
* inicializando-se e às suas tarefas, e então executa o PM e o FS. Tanto o PM 
quanto o FS se inicializam o máximo que podem. O solicita ao núcleo toda a 
memória livre e começa a atender requisições. 


* 


* Os pontos de entrada para este aquivos são: 
main: inicia a execução do PM 
setreply: resposta a ser enviada para o processo que faz chamada de sistema do PM 


* 


*/ 


tinclude "pm.h" 

tinclude <minix/keymap.h> 
tinclude <minix/calinr.h> 
tinclude <minix/com.h> 
tinclude <signal.h> 
#include <stdlib.h> 
#include <fcnt1.h> 
#include <sys/resource.h> 
#include <string.h> 
#include "mproc.h" 
#include "param.h" 


#include "../../kernel/const.h" 
#include "../../kernel/config.h" 
#include "../../kernel/type.h" 
#include "../../kernel/proc.h" 


FORWARD _PROTOTYPE(Ç void get work, (void) ) 

FORWARD _PROTOTYPE( void pm init, (void) J; 

FORWARD _PROTOTYPE(Ç int get nice value, (int queue) ) 

FORWARD | PROTOTYPE( void get_mem_chunks, (struct memory *mem_chunks) ) 

FORWARD | PROTOTYPE( void patch_mem_chunks, (struct memory *mem_chunks, 
struct mem_map *map_ptr) ); 


#define click_to_round_k(n) \ 
CCunsigned) ((CCunsigned Tong) (n) << CLICK SHIFT) + 512) / 1024)) 


PUBLIC int main 

{ 

/* Rotina principal do gerenciador de processos. */ 
int result, s, proc_nr; 
struct mproc *rmp; 
sigset_t sigset; 


pm_initO; /* inicializa as tabelas do gerenciador de processos */ 
/* Este é o loop principal do PM - obtém trabalho e o executa, para sempre e sempre. */ 
while (TRUE) 1 

get work (); /* espera por uma chamada de sistema de PM */ 


/* Verifica primeiro notificações de sistema. Casos especiais. */ 
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18055 if (call nr == SYN ALARM) { 

18056 pm expire timers(m in.NOTIFY TIMESTAMP) ; 

18057 result = SUSPEND; /* não responde */ 

18058 } else if (call nr == SYS SIG) { /* sinais pendentes */ 

18059 sigset = m in.NOTIFY ARG; 

18060 if (sigismember(&sigset, SIGKSIG)) (void) ksig pendingO; 

18061 result = SUSPEND; /* não responde */ 

18062 

18063 /* Senão, se o número da chamada de sistema for válido, executa a chamada. */ 
18064 else if ((unsigned) call nr >= NCALLS) { 

18065 result = ENOSYS; 

18066 } else { 

18067 result = (*call_vec[call_nr])O; 

18068 } 

18069 

18070 /* Envia os resultados de volta para o usuário, para indicar término. */ 
18071 if (result != SUSPEND) setreply(who, result); 

18072 

18073 swap in); /* talvez um processo possa ir para a memória? */ 
18074 

18075 /* Envia todas as respostas pendentes, incluindo a resposta para 

18076 * a chamada que acabou de ser feita acima. Os processos não devem ir para o disco. 
18077 &/ 

18078 for (proc nr=0, rmp=mproc; proc nr < NR PROCS; proc nr++, rmp++) { 

18079 /* Nesse meio-tempo, o processo pode ter sido eliminado por um 
18080 * sinal (por exemplo, se um sinal pendente fatal foi desbloqueado) 
18081 * sem que o PM percebesse. Se a entrada não está mais em 

18082 * uso ou é apenas um zumbi, não tenta responder. 

18083 */ 

18084 if CCrmp->mp flags & (REPLY | ONSWAP | IN USE | ZOMBIE)) == 

18085 (REPLY | IN USE)) 1 

18086 if ((s=send(proc nr, &rmp->mp reply)) != OK) 1 

18087 panic(. FILE ,"PM can't reply to", proc nr); 
18088 } 

18089 rmp->mp flags &= “REPLY; 

18090 

18091 } 

18092 } 

18093 return(0K); 

18094 + 

18096  /*========D=D=DDDDDDD=DDDD=DD=D02DD>=2D=DD=DD==2=D=2==>=>==>==2==>==D=>======================* 
18097 x get work * 
18098 PESE ) 
18099 PRIVATE void get work() 

18100 { 

18101 /* Espera pela próxima mensagem e extrai informações úteis dela. */ 

18102 if (receive(ANY, &m in) != OK) panic(. FILE ,"PM receive error", NO NUM); 
18103 who = m in.m source; /* quem enviou a mensagem */ 

18104 call. nr = m in.m type; /* número da chamada de sistema */ 

18105 

18106 /* Entrada do processo que fez a chamada. Usa incorretamente a entrada de processo do 
18107 * próprio PM, caso o núcleo esteja chamando. Isso pode acontecer no caso de alarmes 
18108 * síncronos (CLOCK) ou de um evento como sinais de núcleo pendentes (SYSTEM). 
18109 */ 


18110 mp = &mproc[who < O ? PM PROC NR : who]; 
18111 } 
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ly 


E */ 
PUBLIC void setreply(proc nr, result) 


int proc nr; /* processo para o qual responder */ 
int result; /* resultado da chamada (normalmente OK ou nº do erro) */ 
{ 


/* Cria uma mensagem de resposta a ser enviada posteriormente para um processo de 
* usuário. Ocasionalmente, as chamadas de sistema podem preencher outros campos, isto é 
* apenas para o valor de retorno principal e para ativar o flag "must send reply". 
7 


register struct mproc *rmp = &mproc[proc nr]; 


rmp->mp reply.reply res = result; 
rmp->mp flags |= REPLY; /* resposta pendente */ 


if Crmp->mp flags & ONSWAP) 
swap inqueue(rmp); /* deve transferir esse processo de volta na memória */ 


PRIVATE void pm initO 

{ 
/* Inicializa o gerenciador de processos. 

* A informação de uso da memória é coletada do monitor de inicialização, do núcleo e 

* de todos os processos compilados na imagem do sistema. Inicialmente, essa informação 
é colocada em um array mem chunks. Os elementos de mem chunks são memória de estrutura, 
e contêm pares base, tamanho, em unidades de clicks. Esse array é pequeno, não deve 
* haver mais do que 8 trechos. Após o array de trechos ser construído 
* o conteúdo é usado para inicializar a lista de lacunas. O espaço para a lista de lacunas 
é reservado como um array com duas vezes mais elementos do que o número máximo 
de processos permitidos. Ele é gerenciado como uma lista encadeada e os elementos do 
* array são lacuna de estrutura, que, além de armazenar uma base e tamanho em unidades 
* de click também contém espaço para um vínculo, um ponteiro para outro elemento. 


* 


int s: 

static struct boot_image image[NR_BOOT_PROCS] ; 

register struct boot_image *ip; 

static char core_sigs[] = { SIGQUIT, SIGILL, SIGTRAP, SIGABRT, 
SIGEMT, SIGFPE, SIGUSR1, SIGSEGV, SIGUSR2 }; 

static char ign_sigs[] = { SIGCHLD }; 

register struct mproc *rmp; 

register char *sig_ptr; 

phys_clicks total_clicks, minix_clicks, free_clicks; 

message mess; 

struct mem map mem_map[NR_LOCAL_SEGS] ; 

struct memory mem chunks [NR_MEMS] ; 


/* Inicializa a tabela de processos, incluindo os temporizadores. */ 
for (rmp=&mproc[0]; rmp<&mproc[NR_PROCS]; rmp++) { 
tmr inittimer(&rmp->mp timer); 


} 


/* Constrói o conjunto de sinais que causam core dumps e o conjunto de sinais 
* que são ignorados por padrão. 
*/ 

sigemptyset(&core sset); 

for (sig ptr = core sigs; sig ptr < core sigs+sizeof(core sigs); sig ptr++) 
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18173 sigaddset(&core sset, “sig ptr); 

18174 sigemptyset(&ign sset); 

18175 for (sig ptr = ign sigs; sig ptr < ign sigs+sizeof(ign sigs); sig ptr++) 

18176 sigaddset(&ign sset, *sig ptr); 

18177 

18178 /* Obtém cópia dos parâmetros do monitor de inicialização e da estrutura de informações 
18179 * do núcleo. Analisa a lista de trechos de mem. livre relatada pelo monitor de 
18180 * inicialização, mas deve ser corrigida para os processos do núcleo e do sistema. 
18181 a4 

18182 if ((s=sys getmonparams (monitor params, sizeof(monitor_params))) != OK) 

18183 panic(. FILE ,"get monitor params failed",s); 

18184 get mem chunks (mem chunks) ; 

18185 if ((s=sys getkinfo(&kinfo)) != OK) 

18186 panic(. FILE ,"get kernel info failed",s); 

18187 

18188 /* Obtém o mapa de memória do núcleo para ver a quantidade de memória que ele utiliza. */ 
18189 if ((s=get mem map(SYSTASK, mem map)) != OK) 

18190 panic(. FILE ,"couldn't get memory map of SYSTASK",s); 

18191 minix clicks = (mem map[S] .mem phys+mem map[S] .mem Ten)-mem map[T] .mem phys; 

18192 patch mem chunks (mem chunks, mem map); 

18193 

18194 /* Inicializa a tabela de processos do OM. Solicita uma cópia da tabela da imagem do 
18195 * sistema que é definida no nível do núcleo para ver quais entradas deve preencher. 
18196 */ 

18197 if (OK != (s=sys_getimage(image))) 

18198 panic(_FILE__,"couldn’t get image table: %d\n", s); 

18199 procs_in_use = 0; /* começa a preencher a tabela */ 
18200 printfC"Building tabela de processos:"); /* mostra o que está acontecendo */ 
18201 for (Cip = &image[0]; ip < &image[NR BOOT PROCS]; ip++) 1 

18202 if Cip->proc nr >= 0) 1 /* a tarefa tem nrs negativos */ 
18203 procs in use += 1; /* processo de usuário encontrado */ 
18204 

18205 /* Configura os detalhes do processo encontrados na tabela da imagem. */ 
18206 rmp = &êmproc[ip->proc nr]; 

18207 strncpy(rmp->mp name, ip->proc name, PROC NAME LEN); 

18208 rmp->mp parent = RS PROC NR; 

18209 rmp->mp nice = get nice value(ip->priority); 

18210 if Cip->proc nr == INIT PROC NR) { /* processo de usuário */ 
18211 rmp->mp pid = INIT PID; 

18212 rmp->mp flags |= IN USE; 

18213 sigemptyset (&rmp->mp ignore); 

18214 } 

18215 else { /* processo de sistema */ 
18216 rmp->mp pid = get free pidO; 

18217 rmp->mp flags |= IN USE | DONT SWAP | PRIV. PROC; 

18218 sigfiliset(&rmp->mp ignore); 

18219 } 

18220 sigemptyset(&rmp->mp_sigmask); 

18221 sigemptyset(&rmp->mp_catch); 

18222 sigemptyset(&rmp->mp_sig2mess); 

18223 

18224 /* Obtém mapa de memória para esse processo a partir do núcleo. */ 
18225 if ((s=get mem map(ip->proc nr, rmp->mp_seg)) != OK) 

18226 panic(. FILE ,"couldn't get process entry",s); 

18227 if Crmp->mp seg[T].mem len != 0) rmp->mp flags |= SEPARATE; 

18228 minix clicks += rmp->mp seg[S].mem phys + 

18229 rmp->mp seg[S].mem Ten - rmp->mp seg[T] .mem phys; 

18230 patch mem chunks (mem chunks, rmp->mp seg); 

18231 


18232 /* Informa o FS sobre esse processo de sistema. */ 
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mess.PR PROC NR = ip->proc nr; 
mess.PR PID = rmp->mp pid; 
if (OK != (s=send(FS PROC NR, &mess))) 
panic(. FILE ,"can't sync up with FS", s); 
printf" %s", ip->proc name); /* mostra o nome do processo */ 
} 
} 


printf An'D; /* último processo pronto */ 


/* Ignora alguns detalhes. O PM é muito especial. */ 
mproc[PM PROC NRJ.mp pid = PM PID; /* ignora o pid por mágica */ 
mproc[PM PROC NR].mp parent = PM PROC NR; /* o PM não tem pai */ 


/* Diz ao FS que não existem mais processos de sistema e sincroniza. */ 

mess.PR PROC NR = NONE; 

if (sendrec(FS PROC NR, &mess) != OK || mess.m type != OK) 
panic(. FILE "can't sync up with FS", NO NUM); 


/* Inicializa tabelas para toda memória física e imprime informações de memória. */ 
printfC"Physical memory :"D; 

mem init(mem chunks, &free clicks); 

total clicks = minix clicks + free clicks; 

printf(" total %u KB,", click to round k(total clicks)); 

printf” system %u KB,", click to round kC(minix clicks)); 

printf(" free %u KB.\n", click to round k(free clicks)); 


} 

[É === * 
* get nice value * 
X === * / 

PRIVATE int get nice value(queue) 

int queue; /* armazena trechos de memória */ 

{ 


/* Os processos da imagem de inicialização têm sua prioridade atribuída. O PM não conhece 
* prioridades, mas usa valores 'nice' em seu lugar. A prioridade fica entre 
* MIN USER Q e MAX USER Q. É necessário criar escala entre PRIO MIN e PRIO MAX. 
8/ 

int nice val = (queue - USER Q) * (PRIO MAX-PRIO MIN+1) / 

(MIN USER Q-MAX USER Q+1); 

if (nice val > PRIO MAX) nice val = PRIO MAX; /* não deve acontecer */ 

if (nice val < PRIO MIN) nice val = PRIO MIN; /* não deve acontecer */ 

return nice val; 


} 

Ji 
* get mem chunks * 
X CEDSDSSSSSSSDDSSDDSSS=D=D=================================================== * / 

PRIVATE void get. mem chunks (mem chunks) 

struct memory *mem chunks; /* store mem chunks here */ 

{ 


/* Inicializa a lista de memória livre a partir da variável de inicialização ’memory’. 
* Transforma os deslocamentos de byte e tamanhos dessa lista em clicks, truncados correta- 
* mente. Além disso, certifica-se de que não ultrapassamos o espaço de endereçamento máximo 
* do 286 ou do 8086, isto é, ao executar no modo protegido de 16 bits ou no modo real. 
*/ 
long base, size, limit; 
char *s, *end; /* usa para analisar a variável de inicialização */ 
int i, done = 0; 
struct memory *memp; 
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/* Inicializa tudo como zero. */ 

for Ci = 0; i < NR MEMS; i++) { 
memp = &mem chunks[i]; /* o próximo trecho de memória é armazenado aqui */ 
memp->base = memp->size = 0; 


} 


/* A memória disponível é determinada pelo carregador de inicialização do MINIX como uma 
* lista de pares (base:tamanho) em boothead.s. A variável de inicialização 'memory” é 
* configurada em boot.s. O formato é "b0:s0,b1:s1,b2:s2", onde bO:s0 é a mem inferior, 
* b1:sl é a mem entre 1M e 16M, b2:s2 é a mem acima de 16M. Os pares b1:s1 
* e b2:s2 são combinados, se a memória é adjacente. 

*/ 

s = find_param("memory"); /* obtém a variável de inicialização memory */ 

for Ci = 0; i < NR MEMS && !done; i++) { 


memp = ê&mem chunks[il; /* o próximo trecho de memória é armazenado aqui */ 

base = size = 0; /* inicializa o próximo par base:tamanho */ 

if (és I=0) É /* obtém dados atualizados, a não ser que esteja 
no fim */ 


/* Lê a base atualizada e espera dois-pontos como o próximo caracter. */ 


base = strtoul(s, &end, 0x10); /* obtém número */ 
if (end != s && *end == ’:?°) s = ++end; /* pula "7 */ 
else *s=0; /* termina, não deve acontecer */ 


/* Lê tamanho atualizado e espera vírgula ou presume fim. */ 
size = strtoul(s, &end, 0x10); /* obtém número */ 
if (end != s && *end == ",') s = ++end; /* pula *,* */ 
else done = 1; 

} 

limit = base + size; 

base = (base + CLICK_SIZE-1) & “(Tong)(CLICK SIZE-1); 

limit &= (long) (CLICK_SIZE-1); 

if (limit <= base) continue; 

memp->base = base >> CLICK_SHIFT; 

memp->size = (limit - base) >> CLICK_SHIFT; 


} 

} 
Vi E DEE LE SEE E EENE EEE E E E PARE SS 

ki patch mem chunks * 

fEDDo Lc pes Des O = 4550285 +/ 
PRIVATE void patch mem chunks (mem chunks, map ptr) 
struct memory *mem chunks; /* armazena trechos de mem aqui */ 
struct mem map *map ptr; /* memória a remover */ 
{ 


/* Remove memória do servidor da lista de memória livre. O monitor de inicialização 
* promete colocar os processos no início de trechos de memória. Todas as 
* tarefas usam o mesmo endereço de base; portanto, apenas a primeira tarefa altera 
as listas de memória. Os servidores e init têm seus próprios espaços de 
memória e sua memória será removida da lista. 


* 


*/ 
struct memory *memp; 
for (memp = mem chunks; memp < &mem chunks [NR MEMS]; memp++) 1 
if (memp->base == map ptr[T].mem phys) { 
memp->base += map ptr[T].mem Ten + map ptr[D].mem Ten; 
memp->size -= map ptr[T].mem Ten + map ptr[D].mem Ten; 
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/* Este arquivo trata da criação de processos (via FORK) e de sua exclusão (via 
* EXIT/WAIT). Quando um processo realiza fork, uma nova entrada na tabela 'mproc” é 
* alocada para ele e uma cópia da imagem do núcleo do pai é feita para o 
filho. Então, o núcleo e o sistema de arquivos são informados. Um processo será removido 
da tabela 'mproc” quando dois eventos tiverem ocorrido: (1) ele saiu ou 
* foi eliminado por um sinal e (2) o pai executou uma operação WAIT. Se o processo 
* sai primeiro, ele continua a ocupar uma entrada até que o pai execute uma operação WAIT. 


Os pontos de entrada para este arquivo são: 


* do fork: executa a chamada de sistema FORK 

* do pm exit: executa a chamada de sistema EXIT (chamando pm exit) 
* pm exit: realiza a saída realmente 

* do wait: executa a chamada de sistema WAITPID ou WAIT 


y 


#include "pm.h" 

#include <sys/wait.h> 
#include <minix/callnr.h> 
#include <minix/com.h> 
#include <signal.h> 
#include "mproc.h" 
#include "param.h" 


#define LAST_FEW 2 /* últimas entradas reservadas para o superusuário */ 


FORWARD _PROTOTYPE (void cleanup, (register struct mproc *child) ); 


PUBLIC int do fork() 


{ 

/* O processo apontado por '’mp’ fez fork. Cria um processo filho. */ 
register struct mproc *rmp; /* ponteiro para o pai */ 
register struct mproc *rmc; /* ponteiro para o filho */ 


int child_nr, s; 

phys_clicks prog_clicks, child_base; 

phys bytes prog bytes, parent abs, child abs; /* somente para Intel */ 
pid t new pid; 


/* Se as tabelas puderem ser preenchidas durante a operação FORK, nem mesmo começa, 
* pois a recuperação no meio do caminho é um incômodo. 
*/ 
rmp = mp; 
if (Cprocs in use == NR PROCS) || 
(procs in use >= NR PROCS-LAST FEW && rmp->mp effuid != 0)) 
{ 
printf("PM: warning, process table is full!\n"); 
return(EAGAIN) ; 
} 


/* Determina a quantidade de memória a alocar. Somente os dados e a pilha precisam 
* ser copiados, pois o segmento de texto é compartilhado ou tem comprimento zero. 
* 

E 
prog_clicks = (phys_clicks) rmp->mp_seg[S].mem_len; 
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prog clicks += (rmp->mp seg[S].mem vir - rmp->mp seg[D] .mem vir); 
prog bytes = (phys bytes) prog clicks << CLICK SHIFT; 
if C (child base = alloc memlprog clicks)) == NO MEM) return(ENOMEM) ; 


/* Cria uma cópia da imagem do núcleo do pai para o filho. */ 
child abs = (phys bytes) child base << CLICK SHIFT; 

parent abs = (phys bytes) rmp->mp seg[D].mem phys << CLICK SHIFT; 
s = sys abscopy(parent abs, child abs, prog bytes); 

if (s < 0) panic( FILE ,"do fork can't copy”, s); 


/* Encontra uma entrada em 'mproc” para o processo filho. Deve existir uma entrada. * 


for (rmc = &mproc[0]; rmc < &mproc[NR PROCS]; rmc++) 
if (C Crmc->mp flags & IN USE) == 0) break; 


/* Configura o filho e seu mapa de memória; copia sua entrada 'mproc” do pai. */ 


child nr = (int)(rmc - mproc); /* número da entrada do filho */ 
procs in use++; 

*rmc = *rmp; /* copia a entrada de processo do pai na do filho */ 
rmc->mp parent = who; /* registra o pai do filho */ 


/* herda apenas estes flags */ 
rmc->mp flags &= (IN USE|SEPARATE|PRIV PROC|DONT SWAP) ; 


rmc->mp child utime = 0; /* reconfigura a administração */ 
rmc->mp child stime = 0; /* reconfigura a administração */ 


/* Um filho com I&D separado mantém o segmento de texto dos pais. Os segmentos de 
* dados e de pilha devem se referir à nova cópia. 
*/ 
if (!Crmc->mp flags & SEPARATE)) rmc->mp_seg[T].mem_phys = child base; 
rmc->mp seg[D].mem phys = child base; 
rmc->mp seg[S].mem phys = rmc->mp seg[D].mem phys + 
Crmp->mp seg[S].mem vir - rmp->mp seg[D] .mem vir); 
rmc->mp exitstatus = 0; 
rmc->mp sigstatus = 0; 


/* Encontra um pid livre para o filho e o coloca na tabela. */ 
new pid = get free pid(; 
rmc->mp pid = new pid; /* atribui o pid ao filho */ 


/* Informa ao núcleo e ao FS sobre a operação FORK (agora bem-sucedida). */ 
sys fork(who, child nr); 
tell fs(FORK, who, child nr, rmc->mp pid); 


/* Relata o mapa de memória do filho para o núcleo. */ 
sys newmap(child nr, rmc->mp seg); 


/* Responde para o filho para despertá-lo. */ 


setreply(Cchild nr, 0); /* apenas o pai obtém os detalhes */ 
rmp->mp reply.procnr = child nr; /* número de processo do filho */ 
return(new pid); /* pid do filho */ 


PUBLIC int do pm exitO 


/* Executa a chamada de sistema exit(status). O trabalho real é feito por pm exit, 


* que também é chamada quando um processo é eliminado por um sinal. 
*/ 


pm exit(mp, m in.status); 
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return (SUSPEND); /* não pode se comunicar do além */ 

} 
Jennan a a >> * 

* pm_exit » 

eee EE E EE E E 
PUBLIC void pm_exit(rmp, exit status) 

register struct mproc *rmp; /* ponteiro para o processo a ser terminado */ 
int exit status; /* o status de saída do processo (para o pai) */ 
{ 


/* Um processo está pronto. Libera a maior parte das posses do processo. Se seu 

* pai estiver esperando, libera o restante, setão mantém a entrada do processo e 
* se torna um zumbi. 
*/ 

register int proc_nr; 

int parent waiting, right child; 
pid t pidarg, procgrp; 

struct mproc *p mp; 

clock t t[5]; 


proc nr = (int) (rmp - mproc); /* obtém número da entrada do processo */ 


/* Lembra do grupo do processo do líder da sessão. */ 
procgrp = Crmp->mp pid == mp->mp procgrp) ? mp->mp procgrp : 0; 


/* Se o processo que saiu tinha um temporizador pendente, elimina-o. */ 
if Crmp->mp flags & ALARM ON) set alarm(proc nr, (unsigned) 0); 


/* Faz a contabilidade: busca os tempos de utilização e acumula no pai. */ 
sys times(proc nr, t); 
p mp = &mproc[rmp->mp parent]; /* pai do processo */ 


p -mp->mp child utime += t[0] + rmp->mp child utime; /* soma o tempo do usuário */ 
pmp->mp child stime += t[1] + rmp->mp child stime; /* soma o tempo do sistema */ 


/* Informa ao núcleo e ao FS que o processo não é mais executável. */ 


tell fs(EXIT, proc nr, O, 0); /* o sistema de arquivos pode liberar a entrada do proc */ 


sys exit(proc nr); 


/* As mensagens de resposta pendentes do processo eliminado não podem ser distribuídas. */ 


rmp->mp flags &= “REPLY; 


/* Libera a memória ocupada pelo filho. */ 
if (find shareCrmp, rmp->mp ino, rmp->mp dev, rmp->mp ctime) == NULL) { 


/* Nenhum outro processo compartilha o segmento de texto; portanto, o libera. 


free mem(rmp->mp seg[T].mem phys, rmp->mp seg[T] .mem Ten); 
} 
/* Libera os segmentos de dados e de pilha. */ 
free mem(rmp->mp seg[D] .mem phys, 
rmp->mp seg[S].mem vir 
+ rmp->mp seg[S].mem Ten - rmp->mp seg[D] .mem vir); 


*/ 


/* A entrada do processo só é liberada se o pai tiver executado uma operação WAIT. */ 


rmp->mp_exitstatus = (char) exit_status; 


pidarg = p_mp->mp_wpid; /* quem está sendo esperado? */ 

parent waiting = p mp->mp flags & WAITING; 

right child = /* o filho satisfaz um dos 3 testes? */ 
(pidarg == -1 || pidarg == rmp->mp pid || -pidarg == rmp->mp procgrp); 


if (parent waiting && right child) 1 
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18575 cleanupC(rmp); /* informa o pai e libera a entrada do filho */ 
18576 } else { 

18577 rmp->mp_flags = IN_USE|ZOMBIE; /* pai não está esperando, torna filho um zumbi */ 
18578 sig_proc(p_mp, SIGCHLD); /* envia ao pai um sinal "child died" */ 
18579 } 

18580 

18581 /* Se o processo tem filhos, os deserda. INIT é o novo pai. */ 

18582 for (rmp = &mproc[0]; rmp < &mproc[NR PROCS]; rmp++) { 

18583 if Crmp->mp flags & IN USE && rmp->mp_parent == proc nr) { 

18584 /* agora, 'rmp' aponta para um filho a ser deserdado. */ 

18585 rmp->mp parent = INIT PROC NR; 

18586 parent waiting = mproc[INIT PROC NRJ].mp flags & WAITING; 

18587 if (parent waiting && (rmp->mp flags & ZOMBIE)) cleanupCrmp); 

18588 } 

18589 } 

18590 

18591 /* Envia um desligamento para o grupo do processo se ele era um líder de sessão. */ 
18592 if (procgrp != 0) check_sig(-procgrp, SIGHUP); 

18593 + 

18595 /f===D=DDDD=DDDDD>DDDD>DDD>DDDD=DDDD=DDDD=DDD==>DD==DDD=>>>>=">>>=">>==>>>==== * 

18596 ii k 

18597 fis 

18598 PUBLIC int do waitpidO 

18599 { 


18600 /* Um processo quer esperar que um filho termine. Se um filho já está 
18601 * esperando, libera estruturas de dados e permite que esta chamada de WAIT termine. Caso 
18602 * contrário, realmente espera. Um processo chamando WAIT nunca recebe uma resposta 


18603 * da maneira usual, no fim do laço principal (a não ser que WNOHANG esteja 

18604 * configurado ou que não exista nenhum filho qualificado). 

18605 * Se um filho já saiu, a rotina cleanupQ) envia a resposta 

18606 * para despertar o processo que fez a chamada. 

18607 * Tanto WAIT como WAITPID são manipulados por este código. 

18608 */ 

18609 register struct mproc *rp; 

18610 int pidarg, options, children; 

18611 

18612 /* Configura variáveis internas, dependendo de ser WAIT ou WAITPID. */ 

18613 pidarg = (call nr == WAIT? -1 : m_in.pid); /* 1° param de waitpid */ 

18614 options = (call nr == WAIT? 0 : m_in.sig_nr); /* 3º param de waitpid */ 

18615 if (pidarg == 0) pidarg = -mp->mp procgrp; /* pidarg < 0 ==> grp proc */ 

18616 

18617 /* Há um filho esperando para ser coletado? Neste ponto, pidarg != O: 

18618 E pidarg > O significa que pidarg é o pid de um processo específico a esperar 
18619 ¥ pidarg == -1 significa wait para qualquer filho 

18620 $ pidarg < -1 significa wait para qualquer filho cujo grupo de processo = -pidarg 
18621 */ 


18622 children = 0; 
18623 for (rp = &mproc[0]; rp < &mproc[NR_PROCS]; rp++) { 


18624 if C Crp->mp flags & IN USE) && rp->mp parent == who) { 

18625 /* O valor de pidarg determina quais filhos são qualificados */ 
18626 if Cpidarg > 0 && pidarg != rp->mp pid) continue; 

18627 if Cpidarg < -1 && -pidarg != rp->mp procgrp) continue; 

18628 

18629 children++; /* este filho é aceitável */ 

18630 if Crp->mp flags & ZOMBIE) { 

18631 /* Este filho satisfaz o teste de pid e saiu. */ 

18632 cleanup(rp); /* este filho já saiu */ 

18633 return (SUSPEND) ; 


18634 3 
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18635 
18636 
18637 
18638 
18639 
18640 
18641 
18642 
18643 
18644 
18645 
18646 
18647 
18648 
18649 
18650 
18651 
18652 
18653 
18654 
18655 


18657 
18658 
18659 
18660 
18661 
18662 
18663 
18664 
18665 
18666 
18667 
18668 
18669 
18670 
18671 
18672 
18673 
18674 
18675 
18676 
18677 
18678 
18679 
18680 
18681 


if CCrp->mp flags & STOPPED) && rp->mp sigstatus) 1 
/* Este filho satisfaz o teste do pid e está sendo rastreado. */ 
mp->mp reply.reply res2 = 0177|Crp->mp sigstatus << 8); 
rp->mp sigstatus = 0; 
return(rp->mp pid); 


} 


/* Nenhum filho qualificado saiu. Espera por um, a menos que não exista nenhum. */ 
if (children > 0) { 
/* Existe pelo menos 1 fliho que satisfaz o teste de pid, mas não saiu. */ 


if Coptions & WNOHANG) return(0); /* o pai não quer esperar */ 

mp->mp_flags |= WAITING; /* o pai quer esperar */ 

mp->mp wpid = (pid t) pidarg; /* salva o pid para depois */ 

return (SUSPEND) ; /* não responde, deixa esperar */ 
} else { 

/* Nenhum filho satisfaz o teste de pid. Retorna erro imediatamente. */ 

return (ECHILD) ; /* não - o pai não tem filhos */ 


PRIVATE void cleanup(child) 
register struct mproc *child; /* informa qual processo está saindo */ 


/* Conclui a saída de um processo. O processo saiu ou foi eliminado 


* por um sinal e seu pai está esperando. 

*/ 

struct mproc *parent = &mproc[child->mp parent]; 
int exitstatus; 


/* Desperta o pai, enviando a mensagem de resposta. */ 

exitstatus = (child->mp exitstatus << 8) | (Cchild->mp sigstatus & 0377); 
parent->mp reply.reply res2 = exitstatus; 

setreply(child->mp parent, child->mp pid); 

parent->mp flags &= “WAITING; /* o pai não está mais esperando */ 


/* Libera a entrada da tabela de processos e reinicializa algum campo. */ 
child->mp pid = 0; 

child->mp flags = 0; 

child->mp child utime = 0; 

child->mp child stime = 0; 

procs in use--; 
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servers/pm/exec.c 


AAA ++ 


18700 
18701 
18702 
18703 
18704 


/* Este arquivo manipula a chamada de sistema EXEC. Ele executa o trabalho a seguir: 


- verifica se as permissões deixam que o arquivo seja executado 
- lê o cabeçalho e extrai os tamanhos 

* - busca os args iniciais e o ambiente do espaço de usuário 

Ei - aloca a memória para o novo processo 
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18705 
18706 
18707 
18708 
18709 
18710 
18711 
18712 
18713 
18714 
18715 
18716 
18717 
18718 
18719 
18720 
18721 
18722 
18723 
18724 
18725 
18726 
18727 
18728 
18729 
18730 
18731 
18732 
18733 
18734 
18735 
18736 
18737 
18738 
18739 
18740 
18741 
18742 
18743 
18744 
18745 
18746 
18747 
18748 
18749 
18750 
18751 
18752 
18753 
18754 
18755 
18756 
18757 
18758 
18759 
18760 
18761 
18762 
18763 
18764 


- copia a pilha inicial do PM no processo 
- lê os segmentos de texto e de dados e copia no processo 
* - cuida dos bits setuid e setgid 
i - corrige a tabela 'mproc” 
- informa o núcleo sobre EXEC 
- salva o deslocamento no argc inicial (para ps) 


* Os pontos de entrada para esse arquivo são: 

do exec: executa a chamada de sistema EXEC 

rw seg: lê ou escreve um segmento em um arquivo 

* find share: encontra um processo cujo segmento de texto pode ser compartilhado 


2 


tinclude "pm.h" 

ginclude <sys/stat.h> 
tinclude <minix/calinr.h> 
tinclude <minix/com.h> 
tinclude <a.out.h> 
ginclude <signal.h> 
ginclude <string.h> 
tinclude "mproc.h" 
tinclude "param.h" 


FORWARD | PROTOTYPE( int new mem, (struct mproc *sh mp, vir bytes text bytes, 
vir bytes data bytes, vir bytes bss bytes, 

vir bytes stk bytes, phys bytes tot bytes) E 
FORWARD | PROTOTYPE( void patch ptr, (char stack[ARG MAX], vir bytes base) ); 
FORWARD | PROTOTYPE( int insert arg, (char stack[ARG MAX], 


vir bytes *stk bytes, char *arg, int replace) j 
FORWARD _PROTOTYPE(Ç char *patch stack, (int fd, char stack[ARG MAX], 
vir bytes *stk bytes, char *script) j; 


FORWARD _PROTOTYPE(Ç int read header, (int fd, int *ft, vir bytes *text_bytes, 
vir bytes “data bytes, vir bytes *bss bytes, 
phys bytes *tot bytes, long *sym bytes, vir clicks sc, 
vir bytes *pc) J; 


#define ESCRIPT (-2000) /* Retornado por read_header para um script #!. */ 
#define PTRSIZE sizeof(char *) /* Tamanho dos ponteiros em argv[] e envp[]. */ 


JË = 
i do_exec z 
Êta DÁ 

PUBLIC int do exec() 

{ 


/* Executa a chamada de execve(name, argv, envp). A biblioteca do usuário constrói 
* uma imagem completa da pilha, incluindo ponteiros, args, ambiente etc. A pilha 
* é copiada em um buffer dentro do PM e, depois, na nova imagem do núcleo. 

*/ 

register struct mproc *rmp; 

struct mproc *sh_mp; 

int m, r, fd, ft, sn; 

static char mbuf[ARG_MAX]; /* buffer para pilha e zeros */ 

static char name buf[PATH MAX]; /* o nome do arquivo a executar */ 
char *new sp, *name, *basename; 

vir bytes src, dst, text bytes, data bytes, bss bytes, stk bytes, vsp; 
phys bytes tot bytes; /* espaço total do programa, incluindo a lacuna */ 
long sym bytes; 

vir clicks sc; 

struct stat s buf[2], *s p; 

vir bytes pc; 
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18765 

18766 /* Realiza algumas verificações de validade. */ 

18767 rmp = mp; 

18768 stk bytes = (vir bytes) m in.stack bytes; 

18769 if (stk bytes > ARG MAX) return(ENOMEM) ; /* pilha grande demais */ 


18770 if (m in.exec len <= 0 || m in.exec len > PATH MAX) returnCEINVAL); 
18771 


18772 /* Obtém o nome do arquivo exec e verifica se o arquivo é executável. */ 

18773 src = (vir bytes) m in.exec name; 

18774 dst = (vir bytes) name buf; 

18775 r = sys datacopy(who, (vir bytes) src, 

18776 PM PROC NR, (vir bytes) dst, (phys bytes) m in.exec Ten); 

18777 if (r != OK) return(r); /* o nome de arquivo não está no seg. de dados do usuário */ 
18778 

18779 /* Busca a pilha do usuário antes de destruir a imagem do núcleo antiga. */ 
18780 src = (vir bytes) m in.stack ptr; 

18781 dst = (vir bytes) mbuf; 

18782 r = sys datacopy(who, (vir bytes) src, 

18783 PM PROC NR, (vir bytes) dst, (phys bytes)stk bytes); 
18784 /* não pode buscar a pilha (por exemplo, endereço virtual inválido) */ 

18785 if (r != OK) return(EACCES); 

18786 

18787 ms 05 /* r = 0 (primeira tentativa) ouj 1 (script interpretado) */ 

18788 name = name buf; /* nome do arquivo a executar. */ 

18789 do { 

18790 s p=&s buf[rl; 

18791 tell fs(CHDIR, who, FALSE, 0); /* troca para o ambiente do FS do usuário */ 
18792 fd = allowed(name, s p, X BIT); /* o arquivo é executável? */ 

18793 if (fd < 0) return(fd); /* o arquivo não era executável */ 
18794 

18795 /* Lê o cabeçalho do arquivo e extrai os tamanhos de segmento. */ 

18796 sc = (stk bytes + CLICK SIZE - 1) >> CLICK SHIFT; 

18797 

18798 m = read header(fd, &ft, &text bytes, &data bytes, &bss bytes, 

18799 &tot bytes, &sym bytes, sc, &pc); 

18800 if (m != ESCRIPT || ++r > 1) break; 


18801 } while (Cname = patch stack(fd, mbuf, &stk bytes, name buf)) != NULL); 
18802 
18803 if (m<0) 1 


18804 close(fd); /* há algo errado com o cabeçalho */ 

18805 return(stk bytes > ARG MAX ? ENOMEM : ENOEXEC); 

18806 } 

18807 

18808 /* O texto do processo pode ser compartilhado com o que já está sendo executado? */ 
18809 sh_mp = find_share(rmp, s_p->st_ino, s_p->st_dev, s_p->st_ctime); 

18810 

18811 /* Aloca nova memória e libera a memória antiga. Corrige o mapa e informa o núcleo. */ 
18812 r = new mem(sh mp, text bytes, data bytes, bss bytes, stk bytes, tot bytes); 

18813 if Cr != 0K) { 

18814 close(fd); /* núcleo insuficiente ou programa grande demais */ 
18815 return(r); 

18816 } 

18817 

18818 /* Salva a identificação do arquivo para permitir que ele seja compartilhado. */ 
18819 rmp->mp_ino = s_p->st_ino; 

18820 rmp->mp_dev = s_p->st_dev; 

18821 rmp->mp_ctime = s_p->st_ctime; 

18822 

18823 /* Emenda a pilha e copia do PM para a nova imagem do núcleo. */ 


18824 vsp = (vir_bytes) rmp->mp_seg[S].mem_vir << CLICK_SHIFT; 
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18825 vsp += (vir bytes) rmp->mp seg[S].mem Ten << CLICK SHIFT; 

18826 vsp -= stk bytes; 

18827 patch ptrC(mbuf, vsp); 

18828 src = (vir bytes) mbuf; 

18829 r = sys datacopy(PM PROC NR, (vir bytes) src, 

18830 who, (vir bytes) vsp, (phys bytes)stk bytes); 
18831 if (Cr != OK) panic( FILE ,"do exec stack copy err on", who); 
18832 


18833 /* Lê os segmentos de texto e de dados. */ 

18834 if (sh mp != NULL) 1 

18835 Tseek(fd, (off t) text bytes, SEEK CUR); /* compartilhado: pula o texto */ 
18836 } else { 

18837 rw_seg(0, fd, who, T, text_bytes); 

18838 } 

18839 rw_seg(0, fd, who, D, data_bytes); 

18840 

18841 close(fd); /* não precisa mais executar o arquivo */ 

18842 


18843 /* Cuida dos bits setuid/setgid. */ 
18844 if (Crmp->mp_flags & TRACED) == 0) { /* suprime, se houver rastreamento */ 


18845 if (s buf[0].st mode & I_SET_UID_BIT) { 

18846 rmp->mp_effuid = s_buf[0].st_uid; 

18847 tell_fs(SETUID,who, (int)rmp->mp_realuid, (int)rmp->mp_effuid); 
18848 } 

18849 if (s_buf[0].st_mode & I_SET_GID_BIT) { 

18850 rmp->mp_effgid = s_buf[0].st_gid; 

18851 tell_fs(SETGID,who, (int)rmp->mp_realgid, (int)rmp->mp_effgid); 
18852 } 

18853 } 

18854 

18855 /* Salva o deslocamento no argc inicial (para ps) */ 

18856 rmp->mp_procargs = vsp; 

18857 

18858 /* Acerta 'mproc”, avisa núcleo do término de exec e zera sinais capturados. */ 
18859 for (sn = 1; sn <= NSIG; sn++) { 

18860 if (sigismember (&rmp->mp catch, sn)) É 

18861 sigdelset(&rmp->mp catch, sn); 

18862 rmp->mp sigact[sn].sa handler = SIG DFL; 

18863 sigemptyset(&rmp->mp sigact[sn].sa mask); 

18864 } 

18865 } 

18866 

18867 rmp->mp_flags &= “SEPARATE; /* desativa o bit SEPARATE */ 

18868 rmp->mp_flags |= ft; /* ativa para arquivos I & D separados */ 

18869 new sp = (char *) vsp; 

18870 

18871 tell_fs(EXEC, who, 0, 0); /* permite que o FS manipule arquivos FD_CLOEXEC */ 
18872 

18873 /* O sistema salvará a linha de comando para depuração, saída de ps(1) etc. */ 
18874 basename = strrchr(name, "/'); 

18875 if (basename == NULL) basename = name; else basename++; 

18876 strncpy (rmp->mp name, basename, PROC NAME LEN-1); 

18877 rmp->mp name[PROC NAME LEN] = “NO”; 

18878 sys exec(who, new sp, basename, pc); 

18879 

18880 /* Causa um sinal se esse processo for rastreado. */ 


18881 if Crmp->mp flags & TRACED) check sig(rmp->mp pid, SIGTRAP); 

18882 

18883 return (SUSPEND) ; /* não responde, o novo programa apenas executa */ 
18884 1 
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18886 
18887 
18888 
18889 
18890 
18891 
18892 
18893 
18894 
18895 
18896 
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18898 
18899 
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18910 
18911 
18912 
18913 
18914 
18915 
18916 
18917 
18918 
18919 
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18925 
18926 
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18928 
18929 
18930 
18931 
18932 
18933 
18934 
18935 
18936 
18937 
18938 
18939 
18940 
18941 
18942 
18943 
18944 


PRIVATE int read header(fd, ft, text bytes, data bytes, bss bytes, 

tot bytes, sym bytes, sc, pc) 
int fd; 
int *ft; 
vir bytes “text bytes; 
vir bytes *data bytes; 
vir bytes *bss bytes; 
phys bytes *tot bytes; 
long *sym bytes; 
vir clicks sc; 
vir bytes *pc; 


{ 


* lugar para retornar número de ft */ 
* lugar para retornar tamanho do texto */ 


* lugar para retornar tamanho de bss */ 
* lugar para retornar tamanho total */ 


* tamanho da pilha em clicks */ 
* ponto de entrada do programa (PC inicial) */ 


O Sra 


/* Lê o cabeçalho e extrai dele os tamanhos do texto, dos dados, de bss e total. */ 


intm, ct; 

vir clicks tc, dc, s vir, dvir; 

phys clicks totc; 

struct exec hdr; /* o cabeçalho de a.out é lido aqui */ 


/* Lê o cabeçalho e verifica o número mágico. O cabeçalho padrão do MINIX 
* é definido em <a.out.h>. Ele consiste em 8 cars, seguidos de 6 valores long. 
* Em seguida, aparecem mais 4 valores long que não são usados aqui. 


z Byte 0: número mágico 0x01 

a Byte 1: número mágico 0x03 

i Byte 2: normal = 0x10 (não verificado, O está OK), I/D separado = 0x20 
= Byte 3: tipo de CPU, Intel de 16 bits = 0x04, Intel de 32 bits = 0x10, 
s Motorola = 0x0B, Sun SPARC = 0x17 

x Byte 4: comprimento do cabeçalho = 0x20 

g Os bytes 5-7 não são usados. 

+ Agora vê os 6 valores long 

E Bytes 8-11: tamanho do segmento de textos em bytes 

¥ Bytes 12-15: tamanho do segmento de dados inicializado em bytes 

E Bytes 16-19: tamanho de bss em bytes 

E Bytes 20-23: ponto de entrada do programa 

z Bytes 24-27: memória total alocada para o programa (texto, dados + pilha) 
E Bytes 28-31: tamanho da tabela de símbolos em bytes 


* Os valores long são representados em uma ordem dependente da máquina, 
* little-endian no 8088, big-endian no 68000. 


* O cabeçalho é seguido diretamente pelos segmentos de texto e de dados, e pela 
* tabela de símbolos (se houver). Os tamanhos são dados no cabeçalho. Apenas os 
* segmentos de texto e de dados são copiados na memória por exec. O cabeçalho é 


* usado apenas aqui. A tabela de símbolos serve para um depurador e 
* é ignorada aqui. 


*/ 
if ((m= read(fd, &hdr, A MINHDR)) < 2) return(ENOEXEC) ; 


/* Script interpretado? */ 
if (CCchar *) &hdr)[0] == "4" && ((char *) &hdr) [1] == "1"5 return(ESCRIPT); 


if (m != A MINHDR) return(ENOEXEC) ; 
/* Verifica o número mágico, o tipo da cpu e os flags. */ 


if (BADMAG(hdr)) return(ENOEXEC) ; 
if Chdr.a cpu != A 180386) return(ENOEXEC) ; 


* descritor de arquivo para ler arquivo de exec */ 


* lugar para retornar tamanho dos dados inicializados */ 


* Tugar para retornar tamanho da tabela de símbolos */ 
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18945 if CChdr.a flags & “(A NSyM | A EXEC | A SEP)) != 0) return(ENOEXEC) ; 
18946 


18947 *ft = ( (hdr.a flags & A SEP) ? SEPARATE : 0); /* I & D separados ou não */ 
18948 

18949 /* Obtém tamanhos do texto e dos dados. */ 

18950 *text bytes = (vir bytes) hdr.a text; /* tamanho do texto em bytes */ 

18951 *data bytes = (vir bytes) hdr.a data; /* tamanho dos dados em bytes */ 

18952 *bss bytes = (vir bytes) hdr.a bss; /* tamanho de bss em bytes */ 

18953 *tot bytes = hdr.a total; /* total de bytes a alocar para o prog */ 
18954 *sym bytes = hdr.a syms; /* tamanho da tabela de símbolos em bytes */ 
18955 if (*tot bytes == 0) return(ENOEXEC) ; 

18956 

18957 if (*ft != SEPARATE) { 

18958 /* Se o espaço I & D não for separado, tudo é considerado dado. Text=0*/ 
18959 *data_bytes += *text_bytes; 

18960 *text_bytes = 0; 

18961 } 

18962 *pc = hdr.a_entry; /* endereço inicial para começar a execução */ 

18963 

18964 /* Verifica se os tamanhos de segmento são viáveis. */ 


18965 tc = ((unsigned long) *text_bytes + CLICK_SIZE - 1) >> CLICK_SHIFT; 
18966 dc = (*data_bytes + *bss_bytes + CLICK_SIZE - 1) >> CLICK_SHIFT; 
18967 totc = (*tot_bytes + CLICK_SIZE - 1) >> CLICK_SHIFT; 


18968 if (dc >= totc) return(ENOEXEC) ; /* a pilha deve ser de pelo menos 1 click */ 
18969 dvir = (*ft == SEPARATE ? O : tc); 

18970 s vir = dvir + (totc - sc); 

18971 m = (dvir + dc > s vir) ? ENOMEM : OK; 

18972 ct = hdr.a hdrlen & BYTE; /* comprimento do cabeçalho */ 


18973 if (ct > A MINHDR) Iseek(fd, (off t) ct, SEEK SET); /* pula cabeçalho não usado */ 
18974 return(m); 


18975 + 

18977 /f===D=DDDD=DDDD>DDD>>DDD=DDDD=>DDD=DDD>=DDD==>DD==>DD===D>>=">>>=">>=">>>====* 

18978 i new_mem * 

18979 $ Deme / 
18980 PRIVATE int new_mem(sh_mp, text_bytes, data_bytes, 

18981 bss_bytes,stk_bytes,tot_bytes) 

18982 struct mproc *sh_mp; /* o texto pode ser compartilhado com este processo */ 
18983 vir_bytes text_bytes; /* tamanho do segmento de texto em bytes */ 

18984 vir_bytes data_bytes; /* tamanho dos dados inicializados em bytes */ 

18985 vir_bytes bss_bytes; /* tamanho de bss em bytes */ 

18986 vir bytes stk bytes; /* tamanho do segmento de pilha inicial em bytes */ 
18987 phys bytes tot bytes; /* memória total a alocar, incluindo a lacuna */ 
18988 { 

18989 /* Aloca nova memória e libera a memória antiga. Altera o mapa e relata 

18990 * o novo mapa para o núcleo. Zera o bss, a lacuna e a pilha da nova imagem do núcleo. 
18991 */ 

18992 

18993 register struct mproc *rmp = mp; 

18994 vir_clicks text_clicks, data_clicks, gap_clicks, stack_clicks, tot_clicks; 


18995 phys_clicks new_base; 
18996 phys_bytes bytes, base, bss_offset; 
18997 int 's; 


18998 

18999 /* Não precisa alocar texto se ele pode ser compartilhado. */ 

19000 if (sh mp != NULL) text bytes = 0; 

19001 

19002 /* Permite que os dados antigos sejam trocados no disco para criar espaço. (O que é 
19003 * realmente uma perda de tempo, pois vamos jogá-los for a de qualquer maneira.) 


19004 */ 
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19005 
19006 
19007 
19008 
19009 
19010 
19011 
19012 
19013 
19014 
19015 
19016 
19017 
19018 
19019 
19020 
19021 
19022 
19023 
19024 
19025 
19026 
19027 
19028 
19029 
19030 
19031 
19032 
19033 
19034 
19035 
19036 
19037 
19038 
19039 
19040 
19041 
19042 
19043 
19044 
19045 
19046 
19047 
19048 
19049 
19050 
19051 
19052 
19053 
19054 
19055 
19056 
19057 
19058 
19059 
19060 
19061 
19062 
19063 
19064 


rmp->mp flags |= WAITING; 


/* Adquire a nova memória. Cada uma das 4 partes: texto, (dados+bss), lacuna, 
* e pilha ocupa um número integral de clicks, começando no limite do click. 
* As partes dos dados e de bss ficam juntas, sem nenhum espaço. 

*j 

text clicks = ((unsigned Tong) text bytes + CLICK SIZE - 1) >> CLICK SHIFT; 

data clicks = (data bytes + bss bytes + CLICK SIZE - 1) >> CLICK SHIFT; 

stack clicks = (stk bytes + CLICK SIZE - 1) >> CLICK SHIFT; 

tot clicks = (tot bytes + CLICK SIZE - 1) >> CLICK SHIFT; 

gap clicks = tot clicks - data clicks - stack clicks; 

if C Cint) gap clicks < 0) return(ENOMEM) ; 


/* Tenta alocar memória para o novo processo. */ 
new base = alloc mem(text clicks + tot clicks); 
if (new base == NO MEM) return(ENOMEM) ; 


/* Obtivemos memória para a nova imagem do núcleo. Libera a antiga. */ 
rmp = mp; 


if (find shareCrmp, rmp->mp ino, rmp->mp dev, rmp->mp ctime) == NULL) { 
/* Nenhum outro processo compartilha o segmento de texto; portanto, o libera. */ 
free mem(rmp->mp seg[T].mem phys, rmp->mp seg[T] .mem Ten); 
} 
/* Libera os segmentos de dados e de pilha. */ 
free mem(rmp->mp seg[D] .mem_phys, 
rmp->mp seg[S].mem vir + rmp->mp seg[S].mem Ten - rmp->mp seg[D] .mem vir); 


/* Agora, ultrapassamos o ponto sem volta. A imagem do núcleo antiga foi 
* perdida para sempre, a memória para uma nova imagem do núcleo foi alocada. Configura 
* e relata o novo mapa. 

*/ 

if (sh mp != NULL) { 

/* Compartilha o segmento de texto. */ 
rmp->mp seg[T] = sh mp->mp seg[T]; 

} else { 

rmp->mp_seg[T].mem_phys = new base; 
rmp->mp seg[T].mem vir = 0; 
rmp->mp seg[T] .mem Ten text clicks; 


} 

rmp->mp seg[D] .mem phys = new base + text clicks; 

rmp->mp seg[D].mem vir = 0; 

rmp->mp seg[D].mem Ten = data clicks; 

rmp->mp seg[S].mem phys = rmp->mp seg[D].mem phys + data clicks + gap clicks; 
rmp->mp seg[S].mem vir = rmp->mp seg[D] .mem vir + data clicks + gap clicks; 
rmp->mp seg[S].mem Ten = stack clicks; 


sys newmap(who, rmp->mp seg); /* informa novo mapa para o núcleo*/ 


/* A memória antiga pode ter sido transferida para o disco, mas a nova memória é real. */ 
rmp->mp flags &= "(WAITING |ONSWAP | SWAPIN) ; 


/* Zera o segmento de bss, lacuna e pilha. */ 

bytes = (phys bytes) (data clicks + gap clicks + stack clicks) << CLICK SHIFT; 
base = (phys bytes) rmp->mp seg[D] .mem phys << CLICK SHIFT; 

bss offset = (data bytes >> CLICK SHIFT) << CLICK SHIFT; 

base += bss offset; 

bytes -= bss offset; 


if ((s=sys memset(0, base, bytes)) != OK) 1 
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19065 panic(. FILE "new mem can't zero”, s); 

19066 } 

19067 

19068 return(0K); 

19069 } 

19071 /* = te 
19072 i patch_ptr x 
19073 $ onay 
19074 PRIVATE void patch_ptr(stack, base) 

19075 char stack[ARG_MAX] ; /* ponteiro para imagem da pilha dentro do PM */ 
19076 vir_bytes base; /* endereço virtual da base da pilha dentro do usuário */ 
19077 4 

19078 /* Ao executar uma chamada de exec(name, argv, envp), o usuário constrói uma imagem 
19079 * de pilha com ponteiros arg e env relativos ao início da pilha. Agora, 

19080 * esses ponteiros devem ser reposicionados, pois a pilha não está posicionada no 
19081 * endereço 0 no espaço de endereçamento de usuário. 

19082 */ 

19083 


19084 char **ap, flag; 
19085 vir bytes v; 


19086 

19087 flag = 0; /* conta o número de ponteiros O vistos */ 
19088 ap = (char **) stack; /* aponta inicialmente para 'nargs” */ 

19089 ap++; /* agora aponta para argv[0] */ 

19090 while (flag < 2) 1 

19091 if (ap >= (char **) &stack[ARG MAX]) return; /* muito ruim */ 

19092 if C*ap != NULL) { 

19093 v = (vir bytes) “ap; /* v é um ponteiro relativo */ 

19094 v += base; /* reposiciona-o */ 

19095 *ap = (char *) vi /* o coloca de volta */ 

19096 } else { 

19097 flag++; 

19098 } 

19099 ap++; 

19100 } 

19101 } 

19103 /* === 
19104 i insert_arg * 
19105 foSDSSSESSSSSSSSSSSSSSSSS ESSES SSSSDESSSESDSSDSSSSSSSSDESDS SEE ed / 
19106 PRIVATE int insert arg(stack, stk bytes, arg, replace) 

19107 char stack[ARG MAX]; /* ponteiro para imagem da pilha dentro do PM */ 
19108 vir bytes *stk bytes; /* tamanho da pilha inicial */ 

19109 char *arg; /* argumento para incluir/substituir como novo argv[0] */ 
19110 int replace; 

19111 { 

19112 /* Emenda a pilha para que arg se torne argv[0]. Cuidado, a pilha pode 

19113 * ser preenchida com lixo, embora normalmente seja parecida com: 

19114 * nargs argv[0] ... argv[nargs-1] NULL envp[0] ... NULL 

19115 * seguido das strings "apontadas" por argv[i] e envp[il. Os 

19116 * ponteiros são, na realidade, deslocamentos a partir do início da pilha. 
19117 * Retorna true se a operação for bem-sucedida. 

19118 zy 

19119 int offset, a0, al, old_bytes = *stk_bytes; 

19120 

19121 /* Anexar arg previamente adiciona pelo menos uma string e um byte zero. */ 
19122 offset = strlen(arg) + 1; 

19123 


19124 a0 = (int) ((char **) stack)[1]; /* argv[0] */ 
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19125 
19126 
19127 
19128 
19129 
19130 
19131 
19132 
19133 
19134 
19135 
19136 
19137 
19138 
19139 
19140 
19141 
19142 
19143 
19144 
19145 
19146 
19147 
19148 
19149 
19150 
19151 
19152 
19153 
19154 
19155 
19156 
19157 


19159 
19160 
19161 
19162 
19163 
19164 
19165 
19166 
19167 
19168 
19169 
19170 
19171 
19172 
19173 
19174 
19175 
19176 
19177 
19178 
19179 
19180 
19181 
19182 
19183 
19184 


if (a0 < 4 * PTRSIZE || a0 >= old bytes) return(FALSE); 


al = a0; /* al apontará para as strings a serem movidas */ 
if (replace) { 
/* Move al para o final de argv[0][] (argv[1] se nargs > 1). */ 
do { 
if (al == old_bytes) return(FALSE); 
--offset; 
+ while (stack[al++] != 0); 
} else { 


offset += PTRSIZE; /* o novo argv[0] precisa de novo ponteiro em argv[] * 


a0 += PTRSIZE; /* posição do novo argv[0][]. */ 
} 


/* a pilha crescerá por offset bytes (ou diminuirá por -offset bytes) */ 
if (C*stk_bytes += offset) > ARG MAX) return(FALSE); 


/* Reposiciona as strings por offset bytes */ 
memmove(stack + al + offset, stack + al, old bytes - al); 


strcpy(stack + a0, arg); /* Coloca arg no novo espaço. */ 


if (lreplace) 1 
/* Dá espaço para um novo argv[0]. */ 
memmove(stack + 2 * PTRSIZE, stack + 1 * PTRSIZE, a0 - 2 * PTRSIZE); 


CCchar **) stack) [0]++; /* nargs++; */ 
} 
/* Agora emenda argv[] e envp[] por offset. */ 
patch_ptr(stack, (vir bytes) offset); 
((char **) stack)[1] = (char *) a0; /* configura argv[0] corretamente */ 
return(TRUE); 


PRIVATE char *patch_stack(fd, stack, stk_bytes, script) 


int fd; /* descritor de arquivo para abrir arquivo de script */ 


char stack[ARG MAX]; /* ponteiro para imagem da pilha dentro do GP */ 
vir bytes *stk bytes; /* tamanho da pilha inicial */ 

char *script; /* nome do script a interpretar */ 

{ 

/* Emenda o vetor de argumento para incluir o nome de caminho do script a ser 


* interpretado e todas as strings na linha &!. Retorna o nome de caminho do 
* interpretador. 


char *sp, *interp = NULL; 
int n; 
enum { INSERT=FALSE, REPLACE=TRUE 3; 


/* Torna script[] o novo argv[0]. */ 
if (linsert arg(stack, stk bytes, script, REPLACE)) return(NULL); 


if (lIseek(fd, 2L, 0) == -1 /* imediatamente atrás do #! */ 
|| (n= read(fd, script, PATH MAX)) < 0 /* Tê a linha um */ 
|| Csp= memchrCscript, “An”, n)) == NULL) /* deve ser uma linha correta */ 
return(NULL); 


/* Move sp para trás através de script[], anexando previamente cada string na pilha. */ 
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19185 
19186 
19187 
19188 
19189 
19190 
19191 
19192 
19193 
19194 
19195 
19196 
19197 
19198 
19199 
19200 
19201 
19202 
19203 


19205 
19206 
19207 
19208 
19209 
19210 
19211 
19212 
19213 
19214 
19215 
19216 
19217 
19218 
19219 
19220 
19221 
19222 
19223 
19224 
19225 
19226 
19227 
19228 
19229 
19230 
19231 
19232 
19233 
19234 
19235 
19236 
19237 
19238 
19239 
19240 
19241 
19242 
19243 
19244 


for GD) | 
/* pula espaços atrás do argumento. */ 
while (sp > script && (*--sp ==" " |] *sp ==") O 
if (sp == script) break; 
sp[1] = 0; 
/* Move para o início do argumento. */ 
while (sp > script && sp[-1] != °? °? && sp[-1] != "Nt'D --sp; 


interp = sp; 
if (Clinsert arg(stack, stk bytes, sp, INSERT)) return(NULL); 
} 


/* Arredonda *stk_bytes para o tamanho de um ponteiro para restrições de alinhamento. */ 
*stk bytes= ((*stk_bytes + PTRSIZE - 1) / PTRSIZE) * PTRSIZE; 


close(fd); 
return(interp); 


in 
in 
in 
in 
ph 
{ 

/* 


Ea 


PUBLIC void rw seg(rw, fd, proc, seg, seg bytes0) 


t rw; /* 0 = leitura, 1 = escrita */ 

t fd; /* descritor de arquivo para ler / escrever */ 
t proc; /* número do processo */ 

t seg; /* Ty DousS */ 

ys bytes seg byteso0; /* quanto deve ser transferido/ 


Transfere texto ou dados de/para um arquivo e copia em/de um segmento de processo. 
Esta função é um pouco complicada. A maneira lógica de transferir um 

segmento seria bloco por bloco e copiar cada bloco no/do espaço de 

usuário, um por vez. Isso é lento demais; portanto, fazemos algo sujo aqui, 

a saber, enviamos o espaço de usuário e o endereço virtual para o sistema de arquivos nos 
10 bits superiores do descritor de arquivo e o passamos para o endereço virtual do 
usuário, em vez de um endereço do PM. O sistema de arquivos extrai esses parâmetros 
quando recebe uma chamada de leitura ou escrita do gerenciador de processos, que é 

o único processo que pode usar esse truque. Então, o sistema de arquivos copia o 
segmento inteiro diretamente no/do espaço de usuário, ignorando o PM completamente. 


* A contagem de bytes na leitura normalmente é menor do que a contagem de segmentos, 


#d 


*/ 


pois um segmento é preenchido com um múltiplo de clicks e o segmento de dados só é 
inicializado parcialmente. 


int new_fd, bytes, r; 

char *ubuf_ptr; 

struct mem_map *sp = &mproc[proc].mp_seg[seg]; 
phys_bytes seg_bytes = seg_bytes0; 


new_fd = (proc << 7) | (seg << 5) | fd; 
ubuf_ptr = (char *) ((vir_bytes) sp->mem vir << CLICK SHIFT); 


while (seg bytes != 0) { 
efine PM CHUNK SIZE 8192 
bytes = MINCCINT MAX / PM CHUNK SIZE) * PM CHUNK SIZE, seg bytes); 
if (rw == 0) 1 
r = read(new_fd, ubuf_ptr, bytes); 
} else { 
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19245 
19246 
19247 
19248 
19249 
19250 
19251 


19253 
19254 
19255 
19256 
19257 
19258 
19259 
19260 
19261 
19262 
19263 
19264 
19265 
19266 
19267 
19268 
19269 
19270 
19271 
19272 
19273 
19274 
19275 
19276 
19277 


r = write(new fd, ubuf ptr, bytes); 
} 
if (r != bytes) break; 
ubuf_ptr += bytes; 
seg_bytes -= bytes; 


PUBLIC struct mproc *find_share(mp_ign, ino, dev, ctime) 


struct mproc *mp_ign; /* processo que não deve ser visto */ 

ino_t ino; /* parâmetros que identificam um arquivo exclusivamente */ 
dev_t dev; 

time_t ctime; 

{ 


/* Procura um processo que é o arquivo <ino, dev, ctime> em execução. Não 
* “encontra” mp_ign acidentalmente, pois é o processo em nome do qual essa 
* chamada é feita. 
*/ 
struct mproc *sh_mp; 
for (sh mp = &mproc[0]; sh mp < &mproc[NR PROCS]; sh_mp++) { 


if C!Csh mp->mp flags & SEPARATE)) continue; 


if (sh mp == mp ign) continue; 
if (sh mp->mp ino != ino) continue; 
if (sh mp->mp dev != dev) continue; 
if (sh mp->mp ctime != ctime) continue; 
return sh mp; 
} 
return (NULL); 


} 
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19300 
19301 
19302 
19303 
19304 
19305 
19306 
19307 
19308 
19309 
19310 
19311 
19312 
19313 
19314 
19315 
19316 
19317 
19318 
19319 


/* O modelo de alocação de memória do MINIX reserva uma quantidade de memória fixa 

* para os segmentos de texto, dados e pilha combinados. A quantidade usada para um 

* processo filho criado por FORK é a mesma que o pai tinha. Se o filho 

* executar uma operação EXEC posteriormente, o novo tamanho será extraído do cabeçalho 

* do arquivo que executou essa operação. 

* O layout na memória consiste no segmento de texto, seguido do segmento de 

* dados, seguido de uma lacuna (memória não utilizada), seguida do segmento de pilha. 

* O segmento de dados cresce para cima e a pilha cresce para baixo; portanto, cada um deles 
pode ocupar memória da lacuna. Se eles se encontrarem, o processo deverá ser eliminado. As 
funções deste arquivo tratam do crescimento dos segmentos de dados e de pilha. 


* Os pontos de entrada para este arquivo são: 


* do brk: chamadas de sistema BRK/SBRK para aumentar ou diminuir o segmento de dados 
* adjust: verifica se um ajuste de segmento proposto é permitido 

* size ok: verifica se os tamanhos de segmento são viáveis 

*/ 


tinclude "pm.h" 
ginclude <signal.h> 
ginclude "mproc.h" 
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19320 
19321 
19322 
19323 
19324 
19325 
19326 
19327 
19328 
19329 
19330 
19331 
19332 
19333 
19334 
19335 
19336 
19337 
19338 
19339 
19340 
19341 
19342 
19343 
19344 
19345 
19346 
19347 
19348 
19349 
19350 
19351 
19352 
19353 
19354 
19355 
19356 


19358 
19359 
19360 
19361 
19362 
19363 
19364 
19365 
19366 
19367 
19368 
19369 
19370 
19371 
19372 
19373 
19374 
19375 
19376 
19377 
19378 
19379 


tinclude "param.h" 


tdefine DATA CHANGED 1 /* valor de flag quando tam. do segmento de dados mudou */ 
tdefine STACK CHANGED 2 /* valor de flag quando o tamanho da pilha mudou */ 
[/B============>=>==>=>>=>=>>=>=>=>>=>>=>>>=>=>=>>=>>>>>=>=>=>=>>>>>>>=>>=>>=>>>>>=>=>=>=>===> * 

Ei do brk E 

Y a / 
PUBLIC int do brkO 

{ 
/* Executa a chamada de sistema brk(addr). 

* A chamada é complicada pelo fato de que, em algumas máquinas (por exemplo, o 8088), 

* o ponteiro de pilha pode crescer além da base o segmento de pilha sem 

* que ninguém perceba. 

* O parâmetro ’addr’ é o novo endereço virtual no espaço D. 

*/ 

register struct mproc *rmp; 

int r; 

vir bytes v, new sp; 

vir clicks new clicks; 

rmp = mp; 
= (vir bytes) m in.addr; 
new clicks = (vir clicks) ( ((long) v + CLICK SIZE - 1) >> CLICK SHIFT); 
if (new clicks < rmp->mp seg[D].mem vir) 1 
rmp->mp reply.reply ptr = (char *) -1; 
return (ENOMEM) ; 

} 

new clicks -= rmp->mp_seg[D].mem_vir; 

if (Cr=get_stack_ptr(who, &new_sp)) != OK) /* solicita o valor de sp para o núcleo * 


panic(_ FILE ,"couldn't get stack pointer ", r); 
r = adjust(rmp, new clicks, new sp); 
rmp->mp reply.reply ptr = (r == OK ? m in.addr : (char *) -1); 


return(r); /* retorna o novo endereço ou -1 */ 

} 

/* === ¥ 
% adjust 
EDDS==D=DD=D>=>>>>>>=>>=>=>>=>>=>>>>>>>=>>=>>=>=>>>>>>>=>>=>>>>=>>>>>>>=>>=>>=>>=>>=>==>=>===> * / 

PUBLIC int adjust(rmp, data clicks, sp) 

register struct mproc *rmp; /* a memória de quem está sendo ajustada? */ 

vir clicks data clicks; /* qual será o tamanho do segmento de dados? */ 

vir bytes sp; /* novo valor de sp */ 

{ 


/* Verifica se os segmentos de dados e de pilha podem coexistir, ajustando-os se necessári 


* A memória nunca é alocada ou liberada. Em vez disso, ela é adicionada ou removida da 
* lacuna entre o segmento de dados e o segmento de pilha. Se o tamanho da lacuna se 
* tornar negativo, o ajuste dos dados ou da pilha falhará e ENOMEM será retornado. 


EA 


register struct mem map *mem sp, “mem dp; 
vir clicks sp click, gap base, lower, old clicks; 
int changed, r, ft; 
long base of stack, delta; 


* os valores long evitam certos problemas */ 


mem dp = &rmp->mp seg[D]; 
mem sp = &rmp->mp seg[S]; 
changed = 0; 


* ponteiro para mapa de segmento de dados */ 
* ponteiro para mapa de segmento de pilha */ 
* configura quando um dos dois segmentos mudou */ 


se F 


o. 
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19380 
19381 
19382 
19383 
19384 
19385 
19386 
19387 
19388 
19389 
19390 
19391 
19392 
19393 
19394 
19395 
19396 
19397 
19398 
19399 
19400 
19401 
19402 
19403 
19404 
19405 
19406 
19407 
19408 
19409 
19410 
19411 
19412 
19413 
19414 
19415 
19416 
19417 
19418 
19419 
19420 
19421 
19422 
19423 
19424 
19425 
19426 
19427 
19428 
19429 
19430 


if (mem sp->mem Ten == 0) return(OK); /* não incomoda init */ 


/* Testa se tam. da pilha é negativo (i.é., sp próximo de OxFFFF...); 
base of stack = (long) mem sp->mem vir + (long) mem sp->mem Ten; 


sp click = sp >> CLICK SHIFT; /* click contendo sp */ 


if (sp click >= base of stack) return(ENOMEM); /* sp alto demais */ 


/* Calcula o tamanho da lacuna entre os segmentos de pilha e de dados. */ 


delta = (long) mem sp->mem vir - (long) sp click; 
lower = (delta > 0 ? sp click : mem sp->mem vir); 


/* Margem de segurança para futuro crescimento da pilha. Impossível fazer direito. * 


define SAFETY BYTES (384 * sizeof(char *)) 


define SAFETY CLICKS ((SAFETY BYTES + CLICK SIZE - 1) / CLICK SIZE) 


gap base = mem dp->mem vir + data clicks + SAFETY CLICKS; 
if (lower < gap base) return(ENOMEM); /* os dados e a pilha colidiram */ 


*/ 


/* Atualiza o comprimento dos dados (mas não a orgem dos dados) em nome de brkO. */ 


old clicks = mem dp->mem Ten; 

if (data clicks != mem dp->mem Ten) { 
mem dp->mem Ten = data clicks; 
changed |= DATA CHANGED; 

} 


/* Atualiza o comprimento e a origem da pilha devido à mudança no ponteiro de pilha. */ 


if (delta > 0) 1 
mem sp->mem vir -= delta; 
mem sp->mem phys -= delta; 
mem sp->mem Ten += delta; 
changed |= STACK CHANGED; 
} 


/* Os tamanhos de segmento de dados e de pilha cabem no espaço de endereçamento? */ 


ft = (rmp->mp_flags & SEPARATE); 


r = (rmp->mp_seg[D].mem_vir + rmp->mp_seg[D].mem_len > 


rmp->mp seg[S].mem vir) ? ENOMEM : 
if (Cr ==0K) É 


if (changed) sys newmap((int)(Crmp - mproc), rmp->mp seg); 


return(OK); 
} 


OK; 


/* Novos tam. não cabem ou exigem registradores de página/segmento demais. Restaura. */ 


if (changed & DATA CHANGED) mem dp->mem Ten 
if (changed & STACK CHANGED) 1 
mem sp->mem vir += delta; 
mem sp->mem phys += delta; 
mem sp->mem Ten -= delta; 
} 
return (ENOMEM) ; 


old clicks; 
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19500 
19501 
19502 
19503 
19504 
19505 
19506 
19507 
19508 
19509 
19510 
19511 
19512 
19513 
19514 
19515 
19516 
19517 
19518 
19519 
19520 
19521 
19522 
19523 
19524 
19525 
19526 
19527 
19528 
19529 
19530 
19531 
19532 
19533 
19534 
19535 
19536 
19537 
19538 
19539 
19540 
19541 
19542 
19543 
19544 
19545 
19546 
19547 
19548 
19549 
19550 
19551 
19552 
19553 
19554 


/* 


* 


#i 
#i 
#i 
#i 
#i 
#i 
#i 
#i 
#i 
#i 


#d 
#d 


FO 
FO 
FO 
FO 


PU 
{ 


Este arquivo manipula sinais, os quais são eventos assíncronos e geralmente chegam 
desordenadamente e são chatos de tratar. Os sinais podem ser gerados pela chamada de 
sistema KILL, a partir do teclado (SIGINT) ou a partir do relógio (SIGALRM). 

Em todos os casos, o controle finalmente passa para check sig(), para ver quais 
processos podem ser sinalizados. A sinalização real é feita por sig proc(). 


Os pontos de entrada para esse arquivo são: 
do sigaction: executa a chamada de sistema SIGACTION 
do sigpending: executa a chamada de sistema SIGPENDING 
do sigprocmask: executa a chamada de sistema SIGPROCMASK 
do sigreturn: executa a chamada de sistema SIGRETURN 
do sigsuspend: executa a chamada de sistema SIGSUSPEND 
do kill: executa a chamada de sistema KILL 
do alarm: executa a chamada de sistema ALARM chamando set alarm(O) 
set alarm: diz à tarefa de relógio para iniciar ou parar um temporizador 
do pause: executa a chamada de sistema PAUSE 
ksig pending: o núcleo é notificado sobre sinais pendentes 
sig proc: interrompe ou termina um processo sinalizado 
check sig: verifica quais processos vai sinalizar com sig proc() 
check pending: verifica se um sinal pendente agora pode ser enviado 


a 
a 
a 
a 


nclude "pm.h" 

nclude <sys/stat.h> 
nclude <sys/ptrace.h> 
nclude <minix/callnr.h> 
nclude <minix/com.h> 
nclude <signal.h> 

nclude <sys/sigcontext.h> 
nclude <string.h> 

nclude "mproc.h” 


nclude "param.h” 

efine CORE MODE 0777 /* modo para usar em arquivos de imagem do núcleo */ 
efine DUMPED 0200 /* bit ativado no status quando ocorre core dump*/ 
RWARD | PROTOTYPE( void dump core, (struct mproc *rmp) F 


RWARD _PROTOTYPE( void handle sig, (int proc nr, sigset_t sig map) 


) 
RWARD | PROTOTYPE( void unpause, (int pro) J; 
) 
RWARD _PROTOTYPE( void cause_sigalrm, (struct timer *tp) ) 


BLIC int do_sigactionO 


int rs 
struct sigaction svec; 
struct sigaction *svp; 


if (m_in.sig_nr == SIGKILL) return(OK); 

if (min.signr<1 || min.sig nr > NSIG) return (EINVAL); 

svp = &mp->mp sigact[m in.sig nr]; 

if (Cstruct sigaction *) m in.sig osa != (struct sigaction *) NULL) { 
r = sys datacopy(PM PROC NR, (vir bytes) svp, 
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19555 
19556 
19557 
19558 
19559 
19560 
19561 
19562 
19563 
19564 
19565 
19566 
19567 
19568 
19569 
19570 
19571 
19572 
19573 
19574 
19575 
19576 
19577 
19578 
19579 
19580 
19581 
19582 
19583 
19584 
19585 
19586 
19587 
19588 
19589 
19590 
19591 
19592 


19594 
19595 
19596 
19597 
19598 
19599 
19600 
19601 


19603 
19604 
19605 
19606 
19607 
19608 
19609 
19610 
19611 
19612 
19613 
19614 


who, (vir bytes) m in.sig osa, (phys bytes) sizeof(svec)); 
if (r != OK) return(r); 
} 


if ((struct sigaction *) m in.sig nsa == (struct sigaction *) NULL) 
return(0K); 


/* Lê a estrutura sigaction. */ 
r = sys_datacopy(who, (vir_bytes) m_in.sig_nsa, 

PM PROC NR, (vir bytes) &svec, (phys_bytes) sizeof(svec)); 
if Cr != OK) return(r); 


if (svec.sa handler == SIG IGN) 1 
sigaddset (&êmp->mp ignore, m in.sig nr); 
sigdelset(&mp->mp sigpending, m in.sig nr); 
sigdelset(&êmp->mp catch, m in.sig nr); 
sigdelset(&mp->mp sig2mess, m in.sig nr); 

} else if (svec.sa handler == SIG DFL) 1 
sigdelset(&êmp->mp ignore, m in.sig nr); 
sigdelset(&êmp->mp catch, m in.sig nr); 
sigdelset(&mp->mp sig2mess, m in.sig nr); 

} else if (svec.sa handler == SIG MESS) 1 
if C! (mp->mp flags & PRIV PROC)) return(EPERM) ; 
sigdelset(&mp->mp ignore, m in.sig nr); 
sigaddset (&êmp->mp sig2mess, m in.sig nr); 
sigdelset(&mp->mp catch, m in.sig nr); 

} else { 
sigdelset(&mp->mp_ignore, m_in.sig_nr); 
sigaddset(&mp->mp_catch, m_in.sig_nr); 
sigdelset(&mp->mp_sig2mess, m in.sig nr); 

} 

mp->mp_sigact[m_in.sig_nr].sa_handler = svec.sa_handler; 

sigdelset(&svec.sa mask, SIGKILL); 

mp->mp sigact[m in.sig nr].sa mask = svec.sa mask; 

mp->mp sigact[m in.sig nr].sa flags = svec.sa flags; 

mp->mp sigreturn = (vir bytes) m in.sig ret; 
return(OK); 


do, sigpending 


PUBLIC int do sigpendingO 

{ 
mp->mp_reply.reply_mask = (long) mp->mp_sigpending; 
return OK; 


do sigprocmask 


PUBLIC int do sigprocmask() 

{ 

/* Note que a interface de biblioteca passa a máscara real em sigmask_set e 
* não um ponteiro para a máscara, para economizar uma cópia. Analogamente, 
* a máscara antiga é colocada na mensagem de retorno que a interface de 


* biblioteca copia (se for solicitado) no endereço especificado do usuário. 
* A interface de biblioteca deve configurar SIG INQUIRE se o argumento ’act’ 
* for NULL. 
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19615 */ 

19616 

19617 int i; 

19618 

19619 mp->mp reply.reply mask = (long) mp->mp sigmask; 

19620 

19621 switch (m in.sig how) 1 

19622 case SIG BLOCK: 

19623 sigdelset((sigset t *)&m in.sig set, SIGKILL); 

19624 for Ci = 1; i <= NSIG; i++) { 

19625 if (sigismember((sigset_t *)&m_in.sig_set, i)) 
19626 sigaddset(&mp->mp_sigmask, i); 

19627 } 

19628 break; 

19629 

19630 case SIG_UNBLOCK: 

19631 for Ci = 1; i <= _NSIG; i++) { 

19632 if (sigismember((sigset t *)&m_in.sig_set, i)) 
19633 sigdelset(&mp->mp_sigmask, i); 

19634 } 

19635 check pending(mp); 

19636 break; 

19637 

19638 case SIG SETMASK: 

19639 sigdelset((sigset t *) &m in.sig set, SIGKILL); 

19640 mp->mp sigmask = (sigset t) m in.sig set; 

19641 check pending(mp); 

19642 break; 

19643 

19644 case SIG INQUIRE: 

19645 break; 

19646 

19647 default: 

19648 return(EINVAL); 

19649 break; 

19650 

19651 return OK; 

19652 3 

19654 

19655 $ do_sigsuspend * 
19656 foDDDD=========================>============================================ * / 
19657 PUBLIC int do sigsuspend(O 

19658 { 

19659 mp->mp sigmask2 = mp->mp sigmask; /* salva a máscara antiga */ 
19660 mp->mp sigmask = (sigset t) m in.sig set; 


19661 sigdelset(&mp->mp sigmask, SIGKILL); 
19662 mp->mp flags |= SIGSUSPENDED; 

19663 check pending (mp); 

19664 return (SUSPEND) ; 


19665 + 

19667  /*====DD>D=>D>DDDDDDDDDDDDDDDDDDDDDDDD0DD0D0DDDDDDDD02D0DDDDDDDDDD=2D=D=>==>>=>=>=>==>* 

19668 ii do sigreturn i 

19669 $ Deme ee / 

19670 PUBLIC int do_sigreturnO 

19671 { 

19672 /* Uma rotina de tratamento de sinal do usuário terminou. Restaura o contexto e verifica a 
19673 * existência de sinais desbloqueados pendentes. 


19674 KJ 
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19675 
19676 
19677 
19678 
19679 
19680 
19681 
19682 
19683 
19684 


19686 
19687 
19688 
19689 
19690 
19691 
19692 
19693 
19694 


19696 
19697 
19698 
19699 
19700 
19701 
19702 
19703 
19704 
19705 
19706 
19707 
19708 
19709 
19710 
19711 
19712 
19713 
19714 
19715 
19716 
19717 
19718 
19719 
19720 
19721 
19722 
19723 
19724 


19726 
19727 
19728 
19729 
19730 
19731 
19732 
19733 
19734 


int r; 


mp->mp sigmask = (sigset t) m in.sig set; 
sigdelset(&mp->mp sigmask, SIGKILL); 


r = sys sigreturn(who, (struct sigmsg *) m in.sig context); 
check pending (mp); 
return(r); 


PUBLIC int do kiT1O 
{ 


/* Executa a chamada de sistema kill(pid, signo). */ 


return check_sig(m_in.pid, m_in.sig_nr); 


PUBLIC int ksig_pendingO 
{ 


/* Certos sinais, como as violações de segmentação, são originadas no núcleo. 


* Quando o núcleo detecta esses sinais, ele notifica o PM para executar certas 


ações. O PM pede para o núcleo enviar mensagens com a entrada de processo 


até que todos os sinais sejam manipulados. Se não houver mais sinais, 
* NONE será retornado no campo de número do processo. 

#/. 

int proc_nr; 

sigset_t sig_map; 


while (TRUE) { 


e com o mapa de bits de todos os processos sinalizados. O Sistema de Arquivos, por 
* exemplo, usa esse mecanismo para sinalizar a escrita em pipes quebrados (SIGPIPE). 


O núcleo notificou o PM a respeito de sinais pendentes. Solicita sinais pendentes 


sys_getksig(&proc_nr, &sig_map); /* obtém um sinal pendente arbitrário */ 
if (NONE == proc_nr) { /* pára, se não houver mais sinais pendentes */ 
break; 
} else { 
handle sig(proc nr, sig map); /* manipula o sinal recebido */ 
sys endksig(proc nr); /* informa o núcleo que terminou */ 
} 
return (SUSPEND); /* impede o envio de resposta */ 
} 
/* === ¥ 
* handle sig * 
dD=======D==>>=D>=>>=>>=>=>==>>=>=>>>>>>>>>=>>>>=>>>>=>>>>=>=>>=>>>>>=>>>>==>=>=>>=>>===>==== * / 


PRIVATE void handle sig(proc nr, sig map) 
int proc nr; 
sigset t sig map; 


{ 


register struct mproc *rmp; 
int i; 
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19735 pid t proc id, id; 

19736 

19737 rmp = &mproc[proc nr]; 

19738 if CCrmp->mp flags & (IN USE | ZOMBIE)) != IN USE) return; 
19739 proc id = rmp->mp pid; 


19740 mp = &mproc[0]; /* considera que sinais vem do PM */ 
19741 mp->mp procgrp = rmp->mp procgrp; /* obtém o grupo de processo correto */ 
19742 

19743 /* Verifica cada bit por sua vez para ver se um sinal deve ser enviado. Ao contrário de 
19744 * ki]llO, o núcleo pode coletar vários sinais não relacionados para um 

19745 * processo e passá-los para o PM de uma só vez. Assim, faz um laço no mapa de bits. 
19746 * Para SIGINT e SIGQUIT, usa proc id O para indicar uma transmissão 

19747 * para o grupo de processos do receptor. Para SIGKILL, usa proc id -1 para 
19748 * indicar uma transmissão em nível de sistema. 

19749 */ 

19750 for (i=1; i <= NSIG; i++) { 

19751 if (!sigismember(&sig map, i)) continue; 

19752 switch (Ci) É 

19753 case SIGINT: 

19754 case SIGQUIT: 

19755 id = 0; break; /* transmite para o grupo de processos */ 

19756 case SIGKILL: 

19757 id = -1; break; /* transmite para todos, exceto INIT */ 

19758 default: 

19759 id = proc id; 

19760 break; 

19761 

19762 check sig(id, i); 

19763 

19764 3 

19766 

19767 

19768 

19769 PUBLIC int do alarm() 

19770 { 

19771 /* Executa a chamada de sistema alarm(seconds). */ 

19772 return(set alarm(who, m in.seconds)); 

19773 } 

19775 

19776 

19777 

19778 PUBLIC int set alarm(proc nr, sec) 

19779 int proc nr; /* processo que quer o alarme */ 

19780 int sec; /* quantos segundos deve atrasar antes do sinal */ 
19781 { 

19782 /* Rotina usada por do alarm() para configurar o temporizador de alarme. Também é usada 
19783 * para desligar o temporizador quando um processo sai com o temporizador ainda ativo. 
19784 */ 

19785 clock t ticks; /* número de ticks do alarme */ 

19786 clock t exptime; /* necessário para o tempo restante no alarme anterior */ 
19787 clock t uptime; /* tempo corrente do sistema */ 

19788 int remaining; /* tempo restante anterior em segundos */ 

19789 int sS; 

19790 

19791 /* Primeiro determina o tempo restante do alarme anterior, se estiver configurado. */ 
19792 if (mproc[proc_nr].mp_flags & ALARM_ON) { 

19793 if (C (s=getuptime(&uptime)) != OK) 


19794 panic(_FILE__,"set_alarm couldn't get uptime", s); 
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19795 
19796 
19797 
19798 
19799 
19800 
19801 
19802 
19803 
19804 
19805 
19806 
19807 
19808 
19809 
19810 
19811 
19812 
19813 
19814 
19815 
19816 
19817 
19818 
19819 
19820 
19821 
19822 
19823 
19824 
19825 
19826 
19827 
19828 
19829 
19830 


19832 
19833 
19834 
19835 
19836 
19837 
19838 
19839 
19840 
19841 
19842 
19843 
19844 
19845 
19846 
19847 
19848 


19850 
19851 
19852 
19853 
19854 


exptime = *tmr exp time(&mproc[proc nr].mp timer); 
remaining = (int) ((exptime - uptime + (HZ-1))/HZ); 
if (remaining < 0) remaining = 0; 


} else { 


} 


remaining = 0; 


Diz à tarefa de relógio para fornecer uma mensagem de sinal quando chegar a hora. 


Atrasos grandes causam problemas. Primeiro, a chamada de sistema alarm exige 


contagem de segundos sem sinal e a biblioteca precisa convertê-la em um valor int. 
Isso provavelmente funciona, mas, no retorno, a biblioteca converterá valores sem 
sinal "negativos" em erros. Presumivelmente, ninguém verifica esses erros; portanto, 


obriga essa chamada terminar. Segundo, se unsigned e long têm o mesmo tamanho, 


converter segundos em ticks pode causar um estouro de representação. Finalmente, 


o núcleo tem erros de estouros de representação semelhantes ao somar ticks. 


Corrigir isso exige muitos casts estranhos para adequar os tipos às interfaces 


e evitar interrupções por estouro de representação. ALRM_EXP_TIME tem o tipo correto 


(clock t), embora ele seja declarado como long. Como variáveis como essa 
podem ser declaradas corretamente, sem uma explosão combinada de tipos de 
mensagem? 


ticks = (clock_t) (HZ * (unsigned long) (unsigned) sec); 


if 


if 


C Cunsigned long) ticks / HZ != (unsigned) sec) 
ticks = LONG_MAX; /* eternidade (na verdade, TMR_NEVER) */ 


(ticks != 0) { 
pm_set_timer(&mproc[proc_nr].mp_timer, ticks, cause_sigalrm, proc nr); 
mproc[proc nr].mp flags |= ALARM ON; 


} else if (mprocfproc nr].mp flags & ALARM ON) £ 


} 


pm_cancel_timer(&mproc[proc_nr].mp_timer); 
mproc[proc_nr].mp_flags & “ALARM ON; 


return(remaining); 


PRIVATE void cause sigalrm(tp) 
struct timer *tp; 


{ 


{ 


int proc_nr; 
register struct mproc *rmp; 


proc_nr = tmr_arg(tp)->ta_int; /* obtém processo do temporizador * 


p 
o 


rmp = &mproc[proc nr]; 


if 
if 


CCrmp->mp flags & (IN USE | ZOMBIE)J) != IN USE) return; 
CCrmp->mp flags & ALARM ON) == 0) return; 


rmp->mp flags &= “ALARM ON; 
check sig(rmp->mp pid, SIGALRM); 


PUBLIC int do pause() 
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19855 
19856 
19857 
19858 
19859 


19861 
19862 
19863 
19864 
19865 
19866 
19867 
19868 
19869 
19870 
19871 
19872 
19873 
19874 
19875 
19876 
19877 
19878 
19879 
19880 
19881 
19882 
19883 
19884 
19885 
19886 
19887 
19888 
19889 
19890 
19891 
19892 
19893 
19894 
19895 
19896 
19897 
19898 
19899 
19900 
19901 
19902 
19903 
19904 
19905 
19906 
19907 
19908 
19909 
19910 
19911 
19912 
19913 
19914 


/* Executa a chamada de sistema pause(). */ 


mp->mp flags |= PAUSED; 


return (SUSPEND) ; 
} 
/* === ¥ 
+ sig. proc * 
EEDDS==D=DD=D>=>>=>>=>>=>>=>=>>=>>=>>>>=>>>=>=>=>>=>>>>>=>=>>=>>=>>>>>>>>>=>>=>>>>>>>>>==>=>==== * / 
PUBLIC void sig proc(rmp, signo) 
register struct mproc *rmp; /* ponteiro para o processo a ser sinalizado */ 
int signo; /* sinal a enviar para o processo (de 1 a NSIG) */ 
{ 


/* Envia um sinal para um processo. Verifica se o sinal deve ser capturado, 

* ignorado, transformado em uma mensagem (para processos de sistema) ou bloqueado. 

* — Se o sinal deve ser transformado em uma mensagem, pede para o KERNEL enviar 

para o processo de destino uma notificação de sistema com o sinal pendente como 
argumento. 
*  -—Se o sinal deve ser capturado, pede para o KERNEL colocar uma estrutura 
* sigcontext e uma estrutura sigframe na pilha do captor. Além disso, o KERNEL 
* reconfigurará o contador de programa e o ponteiro de pilha, para que, na próxima vez 
* que o processo executar, execute a rotina de tratamento de sinal. Quando a rotina de 
* tratamento de sinal retornar, sigreturn(2) será chamada. Então, o KERNEL restaurará o 
* contexto do sinal a partir da estrutura sigcontext. 
Se não houver espaço suficiente na pilha, elimina o processo. 


* 


E 


*/ 


vir_bytes new_sp; 
Int S; 

int slot; 

int sigflags; 
struct sigmsg sm; 


slot = (int) (rmp - mproc); 
if CCrmp->mp flags & (IN USE | ZOMBIE)J) != IN USE) 1 
printfC"PM: signal %d sent to %s process %d\n", 
signo, Crmp->mp flags & ZOMBIE) ? "zombie" : "dead", slot); 
panicQ FILE ,"", NO NUM); 
} 
if (Crmp->mp_flags & TRACED) && signo != SIGKILL) { 
/* Um processo rastreado tem tratamento especial. */ 
unpause(slot); 
stop_proc(rmp, signo); /* um sinal faz parar */ 
return; 
} 
/* Alguns sinais são ignorados por padrão. */ 
if (sigismember (&rmp->mp ignore, signo)) { 
return; 
} 
if (sigismember (&rmp->mp sigmask, signo)) { 
/* O sinal deve ser bloqueado. */ 
sigaddset(&rmp->mp sigpending, signo); 
return; 
} 
sigflags = rmp->mp_sigact[signo].sa_flags; 
if (sigismember (&rmp->mp catch, signo)) { 
if Crmp->mp flags & SIGSUSPENDED) 
sm.sm mask = rmp->mp sigmask2; 
else 
sm.sm mask = rmp->mp sigmask; 
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19915 
19916 
19917 
19918 
19919 
19920 
19921 
19922 
19923 
19924 
19925 
19926 
19927 
19928 
19929 
19930 
19931 
19932 
19933 
19934 
19935 
19936 
19937 
19938 
19939 
19940 
19941 
19942 
19943 
19944 
19945 
19946 
19947 
19948 
19949 
19950 
19951 
19952 
19953 
19954 
19955 
19956 
19957 
19958 
19959 
19960 
19961 
19962 
19963 
19964 
19965 
19966 
19967 
19968 


19970 
19971 
19972 
19973 
19974 


sm.sm signo = signo; 


sm.sm sighandler = (vir bytes) rmp->mp sigact[signo].sa handler; 


sm.sm sigreturn = rmp->mp sigreturn; 

if ((s=get stack ptr(slot, &new sp)) != OK) 
panic(. FILE ,"couldn't get new stack pointer",s); 

sm.sm stkptr = new sp; 


/* Cria espaço para as estruturas sigcontext e sigframe. */ 
new sp -= sizeof(struct sigcontext) 


+ 3 * sizeof(char *) + 2 * sizeof(int); 


if (Cadjust(rmp, rmp->mp seg[D] .mem Ten, new sp) != OK) 
goto doterminate; 


rmp->mp sigmask |= rmp->mp sigact[signo].sa mask; 
if (sigflags & SA NODEFER) 

sigdelset(&rmp->mp sigmask, signo); 
else 

sigaddset(&rmp->mp sigmask, signo); 


if (sigflags & SA RESETHAND) 1 
sigdelset(&rmp->mp catch, signo); 
rmp->mp sigact[signo].sa handler = SIG DFL; 
} 


if (OK == (s=sys sigsend(slot, &sm))) { 
sigdelset(&rmp->mp_sigpending, signo); 


/* Se o processo está mantendo PAUSE, WAIT, SIGSUSPEND, 
* pipe, etc., libera-o. 


7 
unpause(slot); 
return; 
} 
panic(__FILE__, "warning, sys_sigsend failed", s); 


else if (sigismember(&rmp->mp_sig2mess, signo)) { 
if (OK != (s=sys_kill(slot,signo))) 
panic(_ FILE , “warning, sys kill failed", s); 
return; 


} 


doterminate: 


/* O sinal não deve ou não pode ser capturado. Executa a ação padrão. * 


if (sigismember(&ign sset, signo)) return; 


rmp->mp sigstatus = (char) signo; 
if (sigismember(&core sset, signo)) 1 


/* Troca para o ambiente do FS do usuário e faz um core dump. */ 


tell fs(CHDIR, slot, FALSE, 0); 
dump core(rmp); 
} 


pm_exit(rmp, 0); /* termina o processo */ 


PUBLIC int check_sig(proc_id, signo) 


tty, 


pid_t proc_id; /* pid of proc to sig, or 0 or -1, or -pgrp */ 
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19975 int signo; /* sinal a ser enviado para o processo (de O a NSIG) */ 
19976 1 

19977 /* Verifica se é possível enviar um sinal. Talvez o sinal tenha de ser 

19978 * enviado para um grupo de processos. Esta rotina é ativada pela chamada de 
19979 * sistema KILL e também quando o núcleo captura um DEL ou outro sinal. 

19980 sy 

19981 

19982 register struct mproc *rmp; 

19983 int count; /* contabiliza a quantidade de sinais enviados */ 
19984 int error_code; 

19985 

19986 if (signo < 0 || signo > _NSIG) return(EINVAL); 

19987 


19988 /* Retorna EINVAL para tentativas de enviar SIGKILL apenas para INIT. */ 
19989 if (proc id == INIT_PID && signo == SIGKILL) return(EINVAL); 


19990 

19991 /* Pesquisa a tabela de processos em busca de processos a sinalizar. (Veja forkexit.c sobre 
19992 * pid mágico.) 

19993 */ 


19994 count = 0; 
19995 error code = ESRCH; 
19996 for (rmp = &mproc[0]; rmp < &mproc[NR PROCS]; rmp++) { 


19997 if C!Crmp->mp flags & IN USE)) continue; 

19998 if CCrmp->mp flags & ZOMBIE) && signo != 0) continue; 

19999 

20000 /* Verifica a seleção. */ 

20001 if (proc id > 0 & proc id != rmp->mp pid) continue; 

20002 if (proc id == 0 && mp->mp procgrp != rmp->mp procgrp) continue; 
20003 if (proc id == -1 && rmp->mp pid <= INIT PID) continue; 

20004 if (proc id < -1 && rmp->mp procgrp != -proc id) continue; 

20005 

20006 /* Verifica a permissão. */ 

20007 if (mp->mp effuid != SUPER USER 

20008 && mp->mp realuid != rmp->mp realuid 

20009 && mp->mp effuid != rmp->mp realuid 

20010 && mp->mp realuid != rmp->mp effuid 

20011 && mp->mp effuid != rmp->mp effuid) { 

20012 error code = EPERM; 

20013 continue; 

20014 fi 

20015 

20016 count++; 

20017 if (signo == 0) continue; 

20018 

20019 /* "sig proc” manipulará a disposição do sinal. O 

20020 * sinal pode ser capturado, bloqueado, ignorado ou causar o término 
20021 * do processo, possivelmente com core dump. 

20022 E 

20023 sig_proc(rmp, signo); 

20024 

20025 if (proc id > 0) break; /* apenas um processo sendo sinalizado */ 
20026 

20027 

20028 /* Se o processo que fez a chamada se eliminou sozinho, não responde. */ 
20029 if CC(mp->mp flags & (IN USE | ZOMBIEJ) != IN USE) return(SUSPEND) ; 
20030 return(count > 0 ? OK : error code); 


20031 } 
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20033 
20034 
20035 
20036 
20037 
20038 
20039 
20040 
20041 
20042 
20043 
20044 
20045 
20046 
20047 
20048 
20049 
20050 
20051 
20052 
20053 
20054 
20055 
20056 
20057 
20058 
20059 
20060 


20062 
20063 
20064 
20065 
20066 
20067 
20068 
20069 
20070 
20071 
20072 
20073 
20074 
20075 
20076 
20077 
20078 
20079 
20080 
20081 
20082 
20083 
20084 
20085 
20086 
20087 
20088 


Jinan a a a 
+ check pending * 
X CODSDSSSSSSSDDSSDDSS==D===================================================== * / 

PUBLIC void check pending(rmp) 

register struct mproc *rmp; 

{ 

/* Verifica se quaisquer sinais pendentes foram desbloqueados. O 
* primeiro sinal desses encontrado é enviado. 
* Se forem encontrados vários sinais pendentes não mascarados, eles serão 
* enviados em seguência. 
* Existem vários lugares neste arquivo onde a máscara de sinal é 
* alterada. Em cada um deles, check pending() deve ser chamada para 
* verificar a existência de sinais recentemente desbloqueados. 
*/ 
int i; 
for Ci = 1; i <= NSIG; i++) { 
if Csigismember(&rmp->mp sigpending, i) && 
Isigismember (&rmp->mp sigmask, i)) { 
sigdelset(&rmp->mp sigpending, i); 
sig procCrmp, i); 
break; 
} 
} 

} 

Je a L 
j unpause * 
oao a a a a a E 

PRIVATE void unpause(pro) 

int pro; /* qual número de processo */ 

{ 

/* Um sinal deve ser enviado para um processo. Se esse processo estiver preso em uma 


chamada de sistema, a chamada de sistema deverá terminar com EINTR. As chamadas 
possíveis são PAUSE, WAIT, READ e WRITE, as duas últimas para pipes e ttys. 


register struct mproc *rmp; 
rmp = &mproc[pro]; 


/* Verifica se o processo está preso em uma chamada de PAUSE, WAIT ou SIGSUSPEND. 
if Crmp->mp flags & (PAUSED | WAITING | SIGSUSPENDED)) { 

rmp->mp flags &= “(PAUSED | WAITING | SIGSUSPENDED) ; 

setreplyCpro, EINTR); 

return; 


} 


Primeiro verifica se o process está preso em uma chamada do PM. Se não estiver, informa, 
ao FS para que ele possa verificar operações READ e WRITE de pipes, ttys e coisas assim. 


*/ 


/* O processo não está preso em uma chamada do PM. Pede ao FS para dar uma olhada. */ 


tell_fs(UNPAUSE, pro, 0, 0); 
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20090 /*========================== * 
20091 ii dump core * 
20092 * ===> ¥Ý / 
20093 PRIVATE void dump_core (rmp) 

20094 register struct mproc *rmp; /* processo que deve sofre core dump */ 

20095 { 

20096 /* Faz um dumo no arquivo "core", se possível. */ 

20097 

20098 int s, fd, seg, slot; 

20099 vir bytes current sp; 

20100 long trace data, trace off; 

20101 

20102 slot = (int) (rmp - mproc); 

20103 

20104 /* O arquivo de core dump? Estamos operando no ambiente do FS do usuário; 
20105 * portanto, nenhuma verificação de permissão especial é necessária. 

20106 fr À 


20107 if Crmp->mp realuid != rmp->mp effuid) return; 
20108 if C (fd = open(core name, O WRONLY | O CREAT | O TRUNC | O NONBLOCK, 


20109 CORE MODE)J) < 0) return; 
20110 rmp->mp sigstatus |= DUMPED; 

20111 

20112 /* Certifica-se de que o segmento de pilha esteja atualizado. 

20113 * Não queremos que adjust() falhe, a não ser que current sp seja absurdo, 
20114 * mas poderia falhar devido a uma verificação de segurança. Além disso, não queremos 
20115 * que adjust() falhe ao enviar um sinal devido à verificação de segurança. 
20116 * Talvez use SAFETY BYTES como um parâmetro. 

20117 zy 

20118 if ((s=get stack ptr(slot, &current_sp)) != OK) 

20119 panic(_ FILE ,"couldn't get new stack pointer",s); 

20120 adjust(rmp, rmp->mp seg[D].mem Ten, current sp); 

20121 

20122 /* Escre o mapa de memória de todos os segmentos para iniciar o arquivo de core. */ 
20123 if (write(fd, (char *) rmp->mp seg, (unsigned) sizeof rmp->mp seg) 

20124 l= (unsigned) sizeof rmp->mp seg) 1 

20125 close(fd); 

20126 return; 

20127 } 

20128 

20129 /* Escreve a entrada da tabela de processos do núcleo inteira para obter os regs. */ 
20130 trace_off = 0; 

20131 while (sys_trace(T_GETUSER, slot, trace_off, &trace_data) == OK) { 

20132 if (write(fd, (char *) &trace_data, (unsigned) sizeof (long)) 

20133 != (unsigned) sizeof (long)) { 

20134 close(fd); 

20135 return; 

20136 } 

20137 trace off += sizeof (long); 

20138 

20139 

20140 /* Faz laço pelos segmentos e escreve os próprios segmentos. */ 

20141 for (seg = 0; seg < NR LOCAL SEGS; seg++) 1 

20142 rw seg(1, fd, slot, seg, 

20143 Cphys bytes) rmp->mp seg[seg].mem Ten << CLICK SHIFT); 

20144 } 


20145 close(fd); 
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HHHHHHHH+H HHHH HHHH HHHH HH HH HH HHHH H+ HHHH HHHH HHHH H+H HHHH H+ HH H+ HH H+H+H+H+H+H+H+H+H+ 


servers/pm/timers.c 


HHHEHHHHHH+HHH+ HHHH HHHH H+H H+ HH HHH HH HHHH HHHH HHHH HHH HHHH HHHH H+HHH+HH+H+HH+H+H+H+H+H+ 


20200 
20201 
20202 
20203 
20204 
20205 
20206 
20207 
20208 
20209 
20210 
20211 
20212 
20213 
20214 
20215 
20216 
20217 
20218 
20219 
20220 
20221 
20222 
20223 
20224 
20225 
20226 
20227 
20228 
20229 
20230 
20231 
20232 
20233 
20234 
20235 
20236 
20237 
20238 
20239 
20240 
20241 
20242 
20243 
20244 
20245 


20247 
20248 
20249 
20250 
20251 
20252 
20253 
20254 


/* Gerenciamento do temporizador de sentinela do PM. As funções deste arquivo fornecem 
* uma interface conveniente para a biblioteca de temporizadores que gerencia uma lista de 
* temporizadores de cão de guarda. Todos os detalhes do escalonamento de um alarme na tarefa 


* CLOCK 


ficam ocultos por trás dessa interface. 


* Portanto, o OM mantém uma lista local de temporizadores para processos de usuário 
* que solicitaram um sinal de alarme. 


* 


Os pontos de entrada para esse arquivo são: 


Apenas os processos de sistema podem configurar um temporizador de alarme no núcleo. 


* pm set timer: reconfigura um temporizador cão de guarda existente ou configura um novo 
* pm expire timers: testa se há temporizadores expirados e executa funções de cão de 


* 


*/ 
tinclude 
tinclude 


tinclude 
tinclude 


guarda pm cancel timer: remove um temporizador da lista de temporizadores 


"pm.h" 


<timers.h> 
<minix/syslib.h> 
<minix/com.h> 


PRIVATE timer_t *pm_timers = NULL; 


Jim 


pm_set_timer 


PUBLIC void pm_set_timer(timer_t *tp, int ticks, tmr_func_t watchdog, int arg) 


{ 


{ 


int r; 
clock t now, prev time = 0, next time; 


if (Cr = getuptime(&now)) != OK) 
panic(C. FILE , "PM couldn't get uptime”, NO NUM); 


/* Configura o argumento do temporizador e adiciona o temporizador na lista. 
tmr arg(tp)->ta int = arg; 
prev time = tmrs settimer(&pm timers,tp,now+ticks,watchdog,&next time); 


/* Reescalona nosso alarme síncrono, se necessário. */ 


if (! prev time || prev time > next time) { 
if (sys setalarm(next time, 1) != OK) 
panic(. FILE , "PM set timer couldn't set alarm.", NO NUM); 
} 
return; 


clock_t next_time; 


/* testa se há temporizadores expirados e possivelmente reescalona um alarme. 


*/ 


*/ 
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20255 tmrs exptimers(&pm timers, now, &next time); 

20256 if (next time > 0) { 

20257 if (sys setalarm(next time, 1) != OK) 

20258 panic(. FILE , "PM expire timer couldn't set alarm.", NO NUM); 
20259 } 

20260 + 

20262 

20263 

20264 

20265 PUBLIC void pm cancel timer(timer t *tp) 

20266 | 

20267 clock t next time, prev time; 

20268 prev time = tmrs clrtimer(&pm timers, tp, &next time); 

20269 

20270 /* Se o temporizador mais antigo foi removido, precisamos configurar o alarme para 
20271 * o próximo temporizador ou cancelar o alarme completamente, caso o último temporizador 
20272 * tenha sido cancelado (então, next time será 0). 

20273 de / 

20274 if (prev time < next time || ! next time) { 

20275 if (sys setalarm(next time, 1) != OK) 

20276 panic(. FILE |, "PM expire timer couldn't set alarm.", NO NUM); 
20277 

20278 + 


DO one Do O O a O + O O DO AD DO HHHH HHHH HHH HHHH H+H HH HHHH HHHH H+ O O O DO OO OO O O 
servers/pm/time.c 
AAA 


20300 /* Este arquivo trata das chamadas de sistema que lidam com tempo. 


20301 + 

20302 * Os pontos de entrada neste arquivo são: 

20303 * do time: executa a chamada de sistema TIME 
20304 * do stime: executa a chamada de sistema STIME 
20305 * do times: executa a chamada de sistema TIMES 
20306 &/ 

20307 


20308 #include "pm.h" 

20309 #include <minix/callnr.h> 
20310 #include <minix/com.h> 
20311 #include <signal.h> 

20312 #include "mproc.h" 

20313 #include "param.h" 


20314 

20315 PRIVATE time_t boottime; 

20316 

20317 

20318 

20319 

20320 PUBLIC int do time() 

20321 { 

20322 /* Executa a chamada de sistema time(tp). Isso retorna o tempo, em segundos, desde 
20323 * 1.1.1970. O MINIX é um sistema astrofisicamente ingênuo, que acha que a terra 
20324 * gira a uma velocidade constante e que coisas como segundos bissextos não 
20325 * existem. 

20326 */ 


20327 clock t uptime; 
20328 int sS; 
20329 
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20330 
20331 
20332 
20333 
20334 
20335 
20336 


20338 
20339 
20340 
20341 
20342 
20343 


20344 
20345 
20346 
20347 
20348 
20349 
20350 
20351 
20352 
20353 
20354 
20355 
20356 
20357 
20358 
20359 
20360 
20361 


20363 
20364 
20365 
20366 
20367 
20368 
20369 
20370 
20371 
20372 
20373 
20374 
20375 
20376 
20377 
20378 
20379 
20380 
20381 
20382 


if C (s=getuptime(&uptime)) != OK) 
panic(_ FILE ,"do time couldn't get uptime”, s); 


mp->mp reply.reply time = (time t) (boottime + (uptime/HZ)); 
mp->mp reply.reply utime = (uptime%HZ)*1000000/HZ; 
return(OK); 


PUBLIC int do stime() 
{ 


/* Executa a chamada de sistema stime(tp). Recupera o tempo de funcionamento do sistema 


(ticks 


* desde a inicialização) e armazena o tempo (em segundos) da inicialização do sistema na 


* variável global "boottime”. 
*/ 

clock t uptime; 

int sS; 


if (mp->mp effuid != SUPER USER) { 
return(EPERM); 


} 

if C (s=getuptime(&uptime)) != OK) 
panic(_ FILE ,"do stime couldn't get uptime", s); 

boottime = (long) m_in.stime - (uptime/HZ); 


/* Também informa ao FS sobre o novo tempo do sistema. */ 
tell_fs(STIME, boottime, 0, 0); 


return(0K); 

} 

/* === ¥ 
* do times * 
EDDS==S==D=D>=>>>>=>>=>>=>=>>=>>=>>=>>=>>>=>>=>>=>>>>>=>=>>=>>=>>>>>>>>>=>>>>=>=>>=>>=>=>=>=>===>"* / 

PUBLIC int do times(O) 

{ 


/* Executa a chamada de sistema times(buffer). */ 
register struct mproc *rmp = mp; 
clock t t[5]; 
int 's; 


if (OK != (s=sys times(who, t))) 

panic( FILE ,"do times couldn't get times", s); 
rmp->mp reply.reply tl = t[0]; /* tempo do usuário */ 
rmp->mp reply.reply t2 = t[1]; /* tempo do sistema */ 
rmp->mp reply.reply t3 = rmp->mp child utime; /* tempo do usuário filho */ 
rmp->mp reply.reply t4 = rmp->mp child stime; /* tempo do sistema filho */ 


rmp->mp reply.reply t5 = t[4]; /* tempo de funcionamento desde inicialização */ 


return(OK); 
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AAA 
servers/pm/getset.c 
DO ssa Do O o a O O O RO HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+H + O SD DO OO OO O O 


20400 /* Este arquivo manipula as 4 chamadas de sistema que obtêm e configuram uids e gids. 


20401 * Ele também manipula getpidO, setsidO e getpgrpO. O código de cada uma 
20402 * é tão pequeno que não valeria a pena tornar cada uma delas uma função 
20403 * separada. 

20404 74 

20405 


20406 #include "pm.h" 

20407 &include <minix/callnr.h> 
20408 #include <signal.h> 

20409 #include "mproc.h” 

20410 &include "param.h” 


20411 

20412 /f=================>>==DD>=D=D=DDDD=2DD=D>D=D=2>==2=>==D>>D=2=>===>===>======>============== * 
20413 + E 
20414 fa=s 

20415 PUBLIC int do getset (O) 

20416 { 

20417 /* Manipula GETUID, GETGID, GETPID, GETPGRP, SETUID, SETGID, SETSID. As quatro 
20418 * GETs e SETSID retornam seus principais resultados em ’r’. GETUID, GETGID e 
20419 * GETPID também retornam resultados secundários (as IDs efetivas ou a ID do 
20420 * processo pai) em "reply res2”, que é retornada para o usuário. 

20421 */ 

20422 

20423 register struct mproc *rmp = mp; 

20424 register int r; 

20425 

20426 switch(call nr) { 

20427 case GETUID: 

20428 r = rmp->mp realuid; 

20429 rmp->mp reply.reply res2 = rmp->mp effuid; 

20430 break; 

20431 

20432 case GETGID: 

20433 r = mp->mp realgid; 

20434 rmp->mp reply.reply res2 = rmp->mp effgid; 

20435 break; 

20436 

20437 case GETPID: 

20438 r = mproc[who].mp pid; 

20439 rmp->mp reply.reply res2 = mproc[rmp->mp parent] .mp pid; 
20440 break; 

20441 

20442 case SETUID: 

20443 if Crmp->mp realuid != (uid t) m in.usr id && 

20444 rmp->mp effuid != SUPER USER) 

20445 return(EPERM); 

20446 rmp->mp realuid = (uid t) min.usr id; 

20447 rmp->mp effuid = (uid t) m in.usr id; 

20448 tell fs(SETUID, who, rmp->mp realuid, rmp->mp effuid); 

20449 r = 0K; 

20450 break; 

20451 

20452 case SETGID: 

20453 if Crmp->mp realgid != (gid_t) m_in.grp_id && 


20454 rmp->mp_effuid != SUPER_USER) 
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return 


} 


return(EPERM); 
rmp->mp realgid = (gid t) min.grp id; 
rmp->mp effgid = (gid t) m in.grp id; 
tell fs(SETGID, who, rmp->mp realgid, rmp->mp effgid); 
= 0K; 
break; 


case SETSID: 
if Crmp->mp procgrp == rmp->mp pid) return(EPERM); 
rmp->mp procgrp = rmp->mp pid; 
tell fs(SETSID, who, O, 0); 
/* falha */ 


case GETPGRP: 
r = rmp->mp procgrp; 
break; 


default: 


= EINVAL; 
break; 


r); 


HEHEHEHEH HHHH HHHH HHHH H+H H+ HH HHH H+H HHHH HHHH ++ 
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HHHEHHHH+HH+H HH HHHH HHHH HHHH HH HHH HH HHHH HHHH ++ 


20500 
20501 
20502 
20503 
20504 
20505 
20506 
20507 
20508 
20509 
20510 
20511 
20512 
20513 
20514 
20515 
20516 
20517 
20518 
20519 
20520 
20521 
20522 
20523 
20524 
20525 
20526 
20527 
20528 
20529 


/* Chamadas de sistema diversas. Autor: Kees J. Bot 


31 de Março de 2000 


* Os pontos de entrada para esse arquivo são: 

* do reboot: elimina todos os processos e, em seguida, reinicializa o sistema 
* do svrctl: controle do gerenciador de processos 

* do getsysinfo: solicita cópia da estrutura de dados do GP (Jorrit N. Herder) 


do getprocnr: pesquisa número de entrada de processo (Jorrit N. Herder) 
do memalloc: aloca um trecho de memória (Jorrit N. Herder) 


* do memfree: desaloca um trecho de memória (Jorrit N. Herder) 
* do getsetpriority: obtém/configura prioridade do processo 


tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 


“"pm.h" 
<minix/calinr.h> 
<signal.h> 
<sys/svrctl.h> 
<sys/resource.h> 
<minix/com.h> 
<string.h> 


PUBLIC int do allocmem() 


{ 


vir_clicks mem_clicks; 
phys_clicks mem_base; 
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20530 mem clicks = (m in.memsize + CLICK SIZE -1 ) >> CLICK SHIFT; 
20531 mem base = alloc mem(mem clicks); 

20532 if (mem base == NO MEM) return(ENOMEM) ; 

20533 mp->mp reply.membase = (phys bytes) (mem base << CLICK SHIFT); 
20534 return(OK); 


20540 PUBLIC int do freemem() 

20541 { 

20542 vir clicks mem clicks; 
20543 phys clicks mem base; 


20545 mem clicks = (m in.memsize + CLICK SIZE -1 ) >> CLICK SHIFT; 
20546 mem base = (m in.membase + CLICK SIZE -1 ) >> CLICK SHIFT; 


20547 free mem(mem base, mem clicks); 

20548 return(OK); 

20549 + 

20551 — A. 
20552 x do_getsysinfo ý 
20553 foDED==========================>============================================ * / 
20554 PUBLIC int do getsysinfoO 

20555 { 

20556 struct mproc *proc addr; 

20557 vir bytes src addr, dst addr; 

20558 struct kinfo kinfo; 

20559 size_t len; 

20560 int s; 

20561 

20562 switch(m_in.info_what) { 

20563 case SI_KINFO: /* a informação do núcleo é obtida via PM */ 
20564 sys_getkinfo(&kinfo); 

20565 src_addr = (vir bytes) &kinfo; 

20566 len = sizeof(struct kinfo); 

20567 break; 

20568 case SI PROC ADDR: /* obtém endereço da tabela de processos do PM */ 
20569 proc addr = &mproc[0]; 

20570 src addr = (vir bytes) &proc addr; 

20571 len = sizeof(struct mproc *); 

20572 break; 

20573 case SI PROC TAB: /* copia a tabela de processos inteira */ 
20574 src addr = (vir bytes) mproc; 

20575 len = sizeof(struct mproc) * NR PROCS; 

20576 break; 

20577 default: 

20578 return(EINVAL); 

20579 

20580 


20581 dst addr = (vir bytes) m in.info where; 

20582 if (OK != (s=sys datacopy(SELF, src addr, who, dst addr, Ten))) 
20583 return(s); 

20584 return(OK); 
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20587 
20588 
20589 
20590 
20591 
20592 
20593 
20594 
20595 
20596 
20597 
20598 
20599 
20600 
20601 
20602 
20603 
20604 
20605 
20606 
20607 
20608 
20609 
20610 
20611 
20612 
20613 
20614 
20615 
20616 
20617 
20618 
20619 
20620 
20621 
20622 
20623 


20625 
20626 
20627 
20628 
20629 
20630 
20631 
20632 
20633 
20634 
20635 
20636 
20637 
20638 
20639 
20640 
20641 
20642 
20643 
20644 
20645 
20646 


P 
{ 


UBLIC int do_getprocnr O) 


register struct mproc *rmp; 

static char search key[PROC NAME LEN+1]; 
int key_len; 

int s: 


if (min.pid >= 0) { /* pesquisa processo pelo pid */ 
for (rmp = &mproc[0]; rmp < &mproc[NR PROCS]; rmp++) 1 
if CCrmp->mp flags & IN USE) && (Crmp->mp pid==m in.pid)) { 
mp->mp reply.procnr = (int) (rmp - mproc); 
return(OK); 
} 
} 
return (ESRCH); 
} else if (m_in.namelen > 0) { /* pesquisa processo pelo nome */ 
key_len = MINC(m in.namelen, PROC NAME LEN); 
if (OK != (s=sys datacopy(who, (vir bytes) m in.addr, 
SELF, (vir bytes) search key, key len))) 
return(s); 
search key[key Ten] = "NO"; /* termina por segurança */ 
for (rmp = &mproc[0]; rmp < &mproc[NR PROCS]; rmp++) { 
if CCrmp->mp flags & IN USE) && 
strncmp(rmp->mp name, search key, key Ten)==0) { 
mp->mp reply.procnr = (int) (rmp - mproc); 
return(OK); 
} 
} 
return(ESRCH) ; 
} else { /* retorna o número do próprio processo */ 
mp->mp_reply.procnr = who; 
} 
return(0K); 


#define REBOOT_CODE "delay; boot" 
PUBLIC int do reboot() 


{ 


char monitor_code[32*sizeof(char *)]; 
int code_len; 
int abort_flag; 


if (mp->mp_effuid != SUPER USER) return(EPERM); 


switch (m in.reboot flag) 1 
case RBT HALT: 
case RBT PANIC: 
case RBT RESET: 
abort flag = m in.reboot flag; 
break; 
case RBT REBOOT: 
code len = strlen(REBOOT CODE) + 1; 
strncpy (monitor code, REBOOT CODE, code Ten); 
abort flag = RBT MONITOR; 
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20647 break; 

20648 case RBT MONITOR: 

20649 code len = m in.reboot strlen + 1; 

20650 if (code Ten > sizeof(monitor code)) return(EINVAL); 

20651 if (sys datacopy(who, (vir bytes) m in.reboot. code, 

20652 PM PROC NR, (vir bytes) monitor code, 

20653 Cphys bytes) (code len)) != OK) return(EFAULT) ; 

20654 if (monitor code[code Ten-1] != 0) return(EINVAL); 

20655 abort flag = RBT MONITOR; 

20656 break; 

20657 default: 

20658 return(EINVAL); 

20659 

20660 

20661 check sig(-1, SIGKILL); /* elimina todos os processos, exceto init */ 
20662 tell fs(REBOOT,0,0,0); /* diz ao FS para preparar-se para o desligamento */ 
20663 

20664 /* Pede ao núcleo para abortar. Todos os serviços de sistema, incluindo o FS receberão 
20665 * uma notificação de HARD STOP. Espera a notificação no laço principal. 
20666 2 

20667 sys_abort(abort_flag, PM_PROC_NR, monitor_code, code_len); 

20668 return (SUSPEND) ; /* não responde para processo eliminado */ 
20669 + 

20671  /*========"==>=>">> 5525555255 5555 50000 ESDDDES E sn de 
20672 id do getsetpriority * 
20673 OCDE SD / 
20674 PUBLIC int do getsetpriorityQO 

20675 { 

20676 int arg which, arg who, arg pri; 

20677 int rmp nr; 

20678 struct mproc *rmp; 

20679 

20680 arg which = m in.ml il; 

20681 arg who = m in.ml i2; 

20682 arg pri =m in.ml i3; /* para SETPRIORITY */ 

20683 

20684 /* Código comum para GETPRIORITY e SETPRIORITY. */ 

20685 

20686 /* Por enquanto, só suporta PRIO PROCESS. */ 

20687 if (arg which != PRIO PROCESS) 

20688 return(EINVAL); 

20689 

20690 if (arg who == 0) 

20691 rmp nr = who; 

20692 else 

20693 if CCrmp nr = proc from pid(arg who)) < 0) 

20694 return(ESRCH); 

20695 

20696 rmp = &êmproc[rmp nr]; 

20697 

20698 if (mp->mp effuid != SUPER USER && 

20699 mp->mp effuid != rmp->mp effuid && mp->mp effuid != rmp->mp realuid) 
20700 return EPERM; 

20701 

20702 /* Se for GET, é isso. */ 

20703 if (call nr == GETPRIORITY) { 

20704 return(rmp->mp nice - PRIO MIN); 

20705 } 


APÊNDICE B e O CóDiGo-FONTE DO MINIX 


863 


20707 
20708 
20709 
20710 
20711 
20712 
20713 
20714 


20716 
20717 
20718 
20719 
20720 
20721 
20722 
20723 
20724 
20725 
20726 
20727 
20728 
20729 
20730 
20731 
20732 
20733 
20734 
20735 
20736 
20737 
20738 
20739 
20740 
20741 
20742 
20743 
20744 
20745 
20746 
20747 
20748 
20749 
20750 
20751 
20752 
20753 
20754 
20755 
20756 
20757 
20758 
20759 
20760 
20761 
20762 
20763 
20764 
20765 
20766 


/* Apenas o superusuário (root) pode reduzir o nível de nice. */ 
if Crmp->mp nice > arg pri && mp->mp effuid != SUPER USER) 
return(EACCES) ; 


/* É SET e é permitido. Faz isso e informa o núcleo. */ 
rmp->mp nice = arg pri; 
return sys nice(rmp nr, arg pri); 


PUBLIC int do svretlQO 
{ 
int s, req; 
vir_bytes ptr; 
#define MAX_LOCAL_PARAMS 2 
static struct { 
char name[30]; 
char value[30]; 
} local_param_overrides[MAX_LOCAL_PARAMS] ; 
static int local params = 0; 


req = m in.svrctl req; 
ptr (vir bytes) m in.svrctl argp; 


/* A requisição é mesmo para o MM? */ 
if (CCreq >> 8) & OxFF) != °M’) return(EINVAL); 


/* Controla operações locais ao PM. */ 
switch(reg) { 
case MMSETPARAM: 
case MMGETPARAM: { 
struct sysgetenv sysgetenv; 
char search key[64]; 
char *val start; 
size_t val len; 
size t copy len; 


/* Copia a estrutura sysgetenv no PM. */ 
if (sys datacopy(who, ptr, SELF, (vir bytes) &sysgetenv, 
sizeof(sysgetenv)) != OK) return(EFAULT); 


/* Configura uma anulação de parâmetro? */ 
if (req == MMSETPARAM) { 
if (local params >= MAX LOCAL PARAMS) return ENOSPC; 
if (sysgetenv.keylen <= 0 
|| sysgetenv.keylen >= 
sizeof(local param overrides[local params] .name) 
|| sysgetenv.vallen <= 0 
|| sysgetenv.vallen >= 
sizeof(local param overrides[local params].value)) 
return EINVAL; 


if ((s = sys datacopy(who, (vir bytes) sysgetenv.key, 
SELF, (vir bytes) local param overrides[local params] .name, 
sysgetenv.keylen)) != OK) 
return s; 
if ((s = sys datacopy(who, (vir bytes) sysgetenv.val, 
SELF, (vir bytes) local param overrides[local params].value, 
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20767 sysgetenv.keylen)) != OK) 

20768 return s; 

20769 local param overrides[local params].name[sysgetenv.keylen] = "N0”; 
20770 local param overrides[local params].value[sysgetenv.vallen] = "10"; 
20771 

20772 local params++; 

20773 

20774 return OK; 

20775 

20776 

20777 if (sysgetenv.keylen == 0) 1 /* copy all parâmetros */ 

20778 val start = monitor params; 

20779 val len = sizeof(monitor params); 

20780 

20781 else { /* pesquisa valor para a tecla */ 
20782 int p; 

20783 /* Tenta obter uma cópia da tecla solicitada. */ 

20784 if (sysgetenv.keylen > sizeof(search key)) return(EINVAL); 
20785 if ((s = sys datacopy(who, (vir bytes) sysgetenv.key, 

20786 SELF, (vir bytes) search key, sysgetenv.keylen)) != OK) 
20787 return(s); 

20788 

20789 /* Certifica-se de que a tecla termine com nulo e pesquisa o valor. 
20790 * Primeiro, verifica anulações locais. 

20791 A 

20792 search key[sysgetenv.keylen-1]= "10"; 

20793 for(p = 0; p < local params; p++) { 

20794 if (!strcmp(search key, local param overridesT[p].name)) 1 
20795 val start = local param overrides[p].value; 

20796 break; 

20797 

20798 } 

20799 if (p >= local_params && (val_start = find_param(search_key)) == NULL) 
20800 return(ESRCH); 

20801 val len = strlen(val start) + 1; 

20802 

20803 

20804 /* Verifica se cabe no buffer do cliente. */ 

20805 if (val len > sysgetenv.vallen) 

20806 return E2BIG; 

20807 

20808 /* Valor encontrado, faz a cópia real (na medida do possível). */ 
20809 copy len = MIN(val Ten, sysgetenv.vallen); 

20810 if ((s=sys datacopy(SELF, (vir bytes) val start, 

20811 who, (vir bytes) sysgetenv.val, copy len)) != OK) 

20812 return(s); 

20813 

20814 return OK; 

20815 

20816 default: 

20817 return(EINVAL); 

20818 } 


20819 } 
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AAA HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHHH H+HH+H+H+H+H+H+H+H++H+H++H++++ 
servers/fs/fs.h 
DO ssa Do O O a O HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O SD DO OO OD O O 


20900 
20901 
20902 
20903 
20904 
20905 
20906 
20907 
20908 
20909 
20910 
20911 
20912 
20913 
20914 
20915 
20916 
20917 
20918 
20919 
20920 
20921 
20922 
20923 
20924 
20925 
20926 


/* Este é o cabeçalho mestre do FS. Ele inclui alguns outros arquivos 
* e define as principais constantes. 


tdefine 
tdefine 
tdefine 


tdefine 


/* O que 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 


tinclude 
tinclude 


tinclude 
tinclude 


tinclude 
tinclude 
tinclude 
tinclude 


-POSIX SOURCE 
-MINIX 
-— SYSTEM 


VERBOSE 


1 
1 
1 


0 


/* diz aos cabeçalhos para incluírem arquivos do POSIX */ 
/* diz aos cabeçalhos para incluírem arquivos do MINIX */ 
/* diz aos cabeçalhos que este é o núcleo */ 


/* exibe mensagens durante a inicialização? */ 


segue é básico, todos os arquivos *.c os obtêm automaticamente. */ 
/* DEVE ser o primeiro */ 
/* DEVE ser o 


<minix/config.h> 
<ansi.h> 
<sys/types.h> 
<minix/const.h> 
<minix/type.h> 
<minix/dmap.h> 


<limits.h> 
<errno.h> 


<minix/syslib.h> 
<minix/sysutil.h> 


"const.h” 
"type.h" 
"proto.h" 
"glo.h” 


segundo */ 


AAA 
servers/fs/const.h 
DO sa Sopa O o a O O HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH HHH O O DO OO O O 


21000 
21001 
21002 
21003 
21004 
21005 
21006 
21007 
21008 
21009 
21010 
21011 
21012 
21013 
21014 
21015 
21016 
21017 
21018 
21019 


/* Taman 
tdefine 
tdefine 
tdefine 
tdefine 


tdefine 
tdefine 
tdefine 
tdefine 


hos de tabela */ 

V1 NR DZONES 7 
V1 NR TZONES 9 
V2 NR DZONES 7 
V2 NR TZONES 10 
NR FILPS 128 
NR INODES 64 
NR SUPERS 8 
NR LOCKS 8 


CE SC RR 


números de 
números de 


* números de 


números de 


* número de 
* número de 


número de 
número de 


/* O tipo de sizeof pode ser (unsigned) Tong. 
* pegar os tamanhos de objetos pequenos, para que não haja surpresas como 


*/ 


tdefine usizeof(t) ((Cunsigned) sizeof(t)) 


/* Tipos de sistema de arquivo. */ 
SUPER MAGIC  0x137F 
SUPER REV 0x7F13 


tdefine 
tdefine 


/* 


/* nr. mágico na leitura de disco do 68000 no PC ou em vv */ 


nr. mágico 


zona diretos em um i-node V1 */ 
zona totais em um i-node V1 */ 
zona diretos em um i-node V2 */ 
zona totais em um i-node V2 */ 


entradas na tabela filp */ 

entradas na tabela de i-nodes "no núcleo" */ 
entradas na tabela de superblocos */ 
entradas na tabela de travas de arquivo */ 


Usa a macro a seguir para 


constantes (small) long sendo passadas para rotinas que esperam um valor int. 


contido no superbloco */ 
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21020 define SUPER V2 0x2468 /* número mágico para sistemas de arquivos V2 */ 
21021 &define SUPER V2 REV 0x6824 /* número mágico V2 gravado no PC, lido no 68K ou vv */ 
21022 #define SUPER V3 0x4d5a /* número mágico para sistemas de arquivos V3 */ 
21023 

21024 &define V1 1 /* número da versão de sistemas de arquivos V1 */ 
21025 &define V2 2 /* número da versão de sistemas de arquivos V2 */ 
21026 #define V3 3 /* número da versão de sistemas de arquivos V3 */ 
21027 

21028 /* Constantes diversas */ 

21029 #define SU UID ((uid_t) 0) /* uid_t de super_user */ 

21030 #define SYS_UID ((uid_t) 0) /* uid_t para os processos GM e INIT */ 

21031 #define SYS GID ((gid_t) 0) /* gid_t para os processos GM e INIT */ 

21032 #define NORMAL 0 /* obriga get block a fazer leitura de disco */ 

21033 gdefine NO READ I /* impede get_block de fazer leitura de disco */ 
21034 #define PREFETCH 2 /* diz para get_block não ler nem marcar dispositivo */ 
21035 

21036 #define XPIPE (-NR_TASKS-1)  /* usado em fp task quando susp no pipe */ 

21037 #define XLOCK (-NR_TASKS-2)  /* usado em fp task quando susp no bloqueio */ 

21038 #define XPOPEN (-NR_TASKS-3)  /* usado em fp task quando susp em pipe aberto */ 
21039 #define XSELECT (-NR_TASKS-4)  /* usado em fp task quando susp na seleção */ 

21040 

21041 #define NO BIT (Cbit t) 0) /* retornado por alloc bit()D para sinalizar falha */ 
21042 

21043 #define DUP MASK 0100 /* máscara para distinguir dup2 de dup */ 

21044 

21045 gdefine LOOK UP O /* diz a search dir para pesquisar string */ 

21046 define ENTER 1 /* diz a search dir para fazer entrada de dir */ 

21047 #define DELETE 2 /* diz a search dir para excluir entrada */ 

21048 define IS EMPTY 3 /* diz a search dir para ret. OK ou ENOTEMPTY */ 

21049 

21050 define CLEAN 0 /* cópias de disco e memória idênticas */ 

21051 &define DIRTY 1 /* cópias de disco e memória diferentes */ 

21052 #define ATIME 002 /* configura se campo atime precisa de atualização */ 
21053 #define CTIME 004 /* configura se campo ctime precisa de atualização */ 
21054 #define MTIME 010 /* configura se campo mtime precisa de atualização */ 
21055 

21056 define BYTE SWAP 0 /* diz a conv2/conv4 para trocar bytes */ 

21057 

21058 &define END OF FILE  (-104) /* eof detectado */ 

21059 

21060 define ROOT INODE 1 /* número de nó-I para diretório-raiz */ 
21061 &define BOOT BLOCK ((block t) 0) /* número do bloco de inicialização */ 

21062 define SUPER BLOCK BYTES (1024) /* deslocamento de bytes */ 

21063 define START BLOCK 2 /* primeiro bloco do FS (sem contar SB) */ 
21064 

21065 define DIR ENTRY SIZE usizeof (struct direct) /* número de bytes/entrada de dir */ 
21066 define NR DIR ENTRIES(b) (Cb)/DIR ENTRY SIZE) /* número de entradas de dir /blc */ 
21067 define SUPER SIZE usizeof (struct super block) /* tamanho de super block */ 
21068 define PIPE SIZE(b) (V1 NR DZONES*(b)) /* tamanho do pipe em bytes */ 
21069 

21070 ádefine FS BITMAP CHUNKS(b) ((b)/usizeof (bitchunk t))/* número trechos/blc do mapa */ 
21071 &define FS BITCHUNK BITS (Cusizeof(bitchunk t) * CHAR BIT) 


21072 &define FS BITS PER BLOCK(b) CFS BITMAP CHUNKS(b) * FS BITCHUNK BITS) 
21073 
21074 /* Tamanhos derivados pertencentes ao sistema de arquivos V1. */ 


21075 define VI ZONE NUM SIZE usizeof (zonel t) /* número de bytes na zona V1 */ 
21076 define V1 INODE SIZE usizeof (dl inode) /* bytes do i-node V1 */ 
21077 


21078 /* número de zonas/bloco indir */ 
21079 &define VI INDIRECTS (STATIC BLOCK SIZE/V1 ZONE NUM SIZE) 
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21080 
21081 /* número de i-nodes/blc no V1 */ 
21082 #define VI INODES PER BLOCK (STATIC BLOCK SIZE/V1 INODE SIZE) 


21083 

21084 /* Tamanhos derivados pertencentes ao sistema de arquivos V2. */ 

21085 define V2 ZONE NUM SIZE usizeof (zone t) /* nº de bytes na zona V2 */ 
21086 define V2 INODE SIZE usizeof (d2 inode) /* bytes do i-node V2 */ 


21087 #define V2 INDIRECTS(b) (Cb)/V2 ZONE NUM SIZE) /* nº de zonas/bloco indir */ 
21088 define V2 INODES PER BLOCK(b) ((b)/V2 INODE SIZE)/* nº de i-nodes/blc do V2 */ 


DO ssa Do O SD O O EO O HHHH HHHH HHHH HHHH HH H+H HH HHHH HHHH H+H O O O DO OO OD O O O 
servers/fs/type.h 
DO spa oo O SS O O +H O O DO OD DO HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO O OO O O 


21100 /* Declaração do i-node V1 conforme aparece no disco (não no núcleo). */ 


21101 typedef struct 1 /* i-node de disco V1.x */ 

21102 mode t dl mode; /* tipo de arquivo, proteção etc. */ 

21103 uid t dl uid; /* id de usuário do proprietário do arquivo */ 

21104 off t dl size; /* tamanho do arquivo corrente em bytes */ 

21105 time t dl mtime; /* quando os dados do arquivo foram alterados pela última vez */ 
21106 ug t dl gid; /* número do grupo */ 

21107 u8 t dl nlinks; /* quantos vínculos para esse arquivo */ 


21108 ul6 t dl zone[V1 NR TZONES]; /* números de bloco para direto, ind e ind dupl */ 
21109 3) di inode; 


21110 

21111 /* Declaração do i-node V2 conforme aparece no disco (não no núcleo). */ 

21112 typedef struct 1 /* i-node de disco V2.x */ 

21113 mode t d2 mode; /* tipo de arquivo, proteção etc. */ 

21114 ul6 t d2 nlinks; /* quantos vínculos para esse arquivo. CORTA! */ 

21115 uid t d2 uid; /* id de usuário do proprietário do arquivo. */ 

21116 ul6 t d2 gid; /* CORTA número de grupo! */ 

21117 off t d2 size; /* tamanho do arquivo corrente em bytes */ 

21118 time t d2 atime; /* quando os dados do arquivo foram acessados pela última vez */ 
21119 time t d2 mtime; /* quando os dados do arquivo foram alterados pela última vez */ 
21120 time t d2 ctime; /* quando os dados do i-node foram alterados pela última vez */ 


21121 zone t d2 zone[V2 NR TZONES]; /* números de bloco para direto, ind e ind dupl */ 
21122 4 d2 inode; 


DO sn Do O O a DD EO HHH HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH O O O O RS DO OO O O DS 
servers/fs/proto.h 
HHHEHEHHHHHHH O OD RO DO HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ O O DO OO OO O O 


21200 /* Prototypes de função. */ 

21201 

21202 &include "timers.h" 

21203 

21204 /* As estruturas usadas em prototypes devem ser declaradas como tal primeiro. */ 
21205 struct buf; 

21206 struct filp; 

21207 struct inode; 

21208 struct super_block; 


21209 

21210 /* cache.c */ 

21211 _PROTOTYPE( zone_t alloc zone, (Dev t dev, zone_t z) Ji 
21212 _PROTOTYPE(Ç void flushall, (Dev t dev) J: 
21213 _PROTOTYPE(Ç void free zone, (Dev_t dev, zone_t numb) J: 


21214 _PROTOTYPE(Ç struct buf *get_block, (Dev t dev, block_t block,int only_search)); 
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21215 | PROTOTYPE( void invalidate, (Dev t device) J 
21216 _PROTOTYPE(Ç void put block, (struct buf *bp, int block type) j; 
21217 _PROTOTYPEÇ void rw block, (struct buf *bp, int rw flag) ) 
21218 _PROTOTYPE(Ç void rw_scattered, (Dev t dev, 

21219 struct buf **bufg, int bufgsize, int rw flag) js 
21220 

21221 /* device.c */ 


21222 _PROTOTYPEÇ int dev open, (Dev t dev, int proc, int flags) J; 
21223 _PROTOTYPE( void dev close, (Dev t dev) Jj; 
21224 _PROTOTYPEÇ int dev io, (int op, Dev_t dev, int proc, void *buf, 

21225 off t pos, int bytes, int flags) i 


) 
21226 _PROTOTYPEÇ int gen_opcl, (int op, Dev_t dev, int proc, int flags) J 
21227 _PROTOTYPE(Ç void gen io, (int task nr, message *mess_ptr) ) 
21228 _PROTOTYPEÇ int no dev, (int op, Dev_t dev, int proc, int flags) ) 
21229 _PROTOTYPEÇ int tty_opcl, (int op, Dev t dev, int proc, int flags) J 
21230 _PROTOTYPE(Ç int ctty_opcl, (int op, Dev_t dev, int proc, int flags) ) 
21231 _PROTOTYPE(Ç int clone opcl, (int op, Dev_t dev, int proc, int flags) J 
21232 _PROTOTYPE(Ç void ctty_io, (int task nr, message *mess_ptr) ) 
21233 | PROTOTYPE( int do_ioctl, (void) ) 
21234 _PROTOTYPE(Ç int do_setsid, (void) ) 
21235 _PROTOTYPE(Ç void dev status, (message *) ) 


21236 

21237 /* dmp.c */ 

21238 _PROTOTYPEÇ int do_fkey_pressed, (void) J; 
21239 


21240 /* dmap.c */ 

21241 _PROTOTYPE(Ç int do_devctl, (void) ) 
21242 _PROTOTYPEÇ void build_dmap, (void) ) 
21243 _PROTOTYPE(Ç int map driver, (int major, int proc nr, int dev style) ) 
21244 

21245 /* filedes.c */ 

21246 _PROTOTYPE(Ç struct filp *find filp, (struct inode *rip, mode t bits) ; 
21247 _PROTOTYPEÇ int get fd, (int start, mode t bits, int *k, struct filp **fpt) ); 


21248 _PROTOTYPE(Ç struct filp *get_filp, Cint fild) Js 
21249 

21250 /* inode.c */ 

21251 | PROTOTYPE( struct inode *alloc inode, (dev t dev, mode t bits) ja 
21252 _PROTOTYPE(Ç void dup inode, (struct inode *ip) Jj; 
21253 |. PROTOTYPE( void free_inode, (Dev_t dev, Ino_t numb) Js 
21254 _PROTOTYPE(Ç struct inode *get_inode, (Dev t dev, int numb) J 
21255 _PROTOTYPE(Ç void put inode, (struct inode *rip) Ji 
21256  PROTOTYPE( void update times, (struct inode *rip) Js 
21257 _PROTOTYPE( void rw_inode, (struct inode *rip, int rw flag) J; 
21258 _PROTOTYPE(Ç void wipe inode, (struct inode *rip) Jj 
21259 

21260 /* link.c */ 

21261 _PROTOTYPE(Ç int do link, (void) j 
21262 _PROTOTYPE(Ç int do unlink, (void) Je 
21263 _PROTOTYPE(Ç( int do rename, (void) 35 
21264 | PROTOTYPE( void truncate, (struct inode *rip) J 
21265 


21266 /* lock.c */ 


21267 | PROTOTYPE( int lock_op, (struct filp *f, int req) J; 
21268 _PROTOTYPE(Ç void lock_revive, (void) j; 
21269 


21270 /* main.c */ 

21271 _PROTOTYPE(Ç int main, (void) 

21272 | PROTOTYPE( void reply, (int whom, int result) 
21273 

21274 /* misc.c */ 


w w 
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21275 
21276 
21277 
21278 
21279 
21280 
21281 
21282 
21283 
21284 
21285 
21286 
21287 
21288 
21289 
21290 
21291 
21292 
21293 
21294 
21295 
21296 
21297 
21298 
21299 
21300 
21301 
21302 
21303 
21304 
21305 
21306 
21307 
21308 
21309 
21310 
21311 
21312 
21313 
21314 
21315 
21316 
21317 
21318 
21319 
21320 
21321 
21322 
21323 
21324 
21325 
21326 
21327 
21328 
21329 
21330 
21334 
21332 
21333 
21334 


- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 


/* mount.c */ 

- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
/* open.c */ 

- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 
PROTOTYPEC int 


/* path.c */ 


- PROTOTYPE( struct inode *advance, (struct inode *dirp, char string[NAME MAX1)); 
PROTOTYPE( int search dir, (struct inode *Tdir ptr, 

char string [NAME MAX], ino t *numb, int flag) 
- PROTOTYPE( struct inode *eat path, (char *path) 

- PROTOTYPE( struct inode *last dir, (char *path, char string [NAME MAX1)); 


/* pipe.c */ 
- PROTOTYPEC int 
- PROTOTYPEC int 


do dup, (void) 

do exit, (void) 
do fcntl, (void) 
do fork, (void) 
do exec, (void) 
do revive, (void) 
do set, (void) 

do sync, (void) 
do fsync, (void) 
do reboot, (void) 
do svrctl, (void) 
do getsysinfo, (void) 


do mount, (void) 
do umount, (void) 
unmount, (Dev t dev) 


do close, (void) 
do creat, (void) 
do Iseek, (void) 
do mknod, (void) 
do mkdir, (void) 
do open, (void) 


do pipe, (void) 
do unpause, (void) 


- PROTOTYPE( void suspend, (int task) 


- PROTOTYPEC int 
- PROTOTYPEC int 
- PROTOTYPEC int 


/* protect.c */ 
- PROTOTYPE( int 
- PROTOTYPE( int 
- PROTOTYPE( int 
- PROTOTYPE( int 
- PROTOTYPE( int 
- PROTOTYPE( int 


/* read.c */ 
- PROTOTYPE( int 


select request pipe, (struct filp *f, int *ops, 
select cancel pipe, (struct filp *f) 
select match pipe, (struct filp *f) >: 


do access, (void) 
do chmod, (void) 
do chown, (void) 
do umask, (void) 


) 
) 


ys 
y 
PROTOTYPE( int pipe check, (struct inode *rip, int rw flag, 

int oflags, int bytes, off t position, int *canwrite, int notouch)); 
- PROTOTYPE( void release, (struct inode *ip, int call nr, int count) Js 
- PROTOTYPE( void revive, (int proc nr, int bytes) y 


forbidden, (struct inode *rip, mode_t access_desired) ); 


read_only, (struct inode *ip) 


do_read, (void) 


- PROTOTYPE( struct buf *rahead, (struct inode *rip, block t baseblock, 


off t position, unsigned bytes ahead) 


- PROTOTYPE( void read ahead, (void) 


- PROTOTYPE( block t read map, (struct inode *rip, off t position) 
- PROTOTYPE( int read write, (int rw flag) 


int bI D; 
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21335  PROTOTYPE( zone t rd indir, (struct buf *bp, int index) J3 
21336 

21337 /* stadir.c */ 

21338 | PROTOTYPE( int do_chdir, (void) ) 
21339  _PROTOTYPE(Ç( int do_fchdir, (void) ) 
21340 | PROTOTYPE( int do_chroot, (void) Ji 
21341 _PROTOTYPE(Ç( int do fstat, (void) ) 
21342 _PROTOTYPEÇ int do stat, (void) ) 
21343 | PROTOTYPE( int do_fstatfs, (void) ) 
21344 

21345 /* super.c */ 

21346 _PROTOTYPE(Ç bit_t alloc_bit, (struct super block *sp, int map, bit_t origin)); 
21347 _PROTOTYPE(Ç void free bit, (struct super block *sp, int map, 


21348 bit t bit returned) >; 
21349 | PROTOTYPE( struct super block *get super, (Dev t dev) J3 
21350 _PROTOTYPE(Ç int mounted, (struct inode *rip) J: 
21351 _PROTOTYPE(Ç int read super, (struct super block *sp) J? 
21352 _PROTOTYPE(Ç int get block size, (dev t dev) J 
21353 

21354 /* time.c */ 

21355  _PROTOTYPE(Ç int do_stime, (void) Ja 
21356  _PROTOTYPE(Ç( int do_utime, (void) Ji 
21357 

21358 /* utility.c */ 

21359 — PROTOTYPE( time t clock time, (void) Ji 
21360 _PROTOTYPE(Ç unsigned conv2, (int norm, int w) Ja 
21361 _PROTOTYPEÇ long conv4, (int norm, long x) y: 
21362 _PROTOTYPE(Ç int fetch name, (char *path, int len, int flag) J; 
21363 _PROTOTYPE(Ç int no sys, (void) DE 
21364 _PROTOTYPE(Ç void panic, (char *who, char *mess, int num) js 
21365 


21366 /* write.c */ 

21367 _PROTOTYPE(Ç void clear zone, (struct inode *rip, off t pos, int flag) ); 
21368  _PROTOTYPE(Ç int do write, (void) ) 
21369 | PROTOTYPE( struct buf *new block, (struct inode *rip, off t position) ); 
21370 | PROTOTYPE( void zero block, (struct buf *bp) ) 


21371 

21372 /* select.c */ 

21373 |. PROTOTYPE( int do select, (void) Js 
21374 _PROTOTYPE(Ç int select callback, (struct filp *, int ops) j; 
21375 _PROTOTYPE(Ç void select forget, (int fproc) j; 
21376 _PROTOTYPE( void select timeout check, (timer t *) 35 
21377 | PROTOTYPE( void init select, (void) J; 
21378 | PROTOTYPE( int select notified, (int major, int minor, int ops) J; 
21379 


21380 /* timers.c */ 
21381 _PROTOTYPE(Ç void fs set timer, (timer_t *tp, int delta, tmr_func_t watchdog, int arg)); 


21382 _PROTOTYPE(Ç void fs_expire_timers, (clock t now) Js 
21383 _PROTOTYPE(Ç void fs cancel timer, (timer_t *tp) Ji 
21384 _PROTOTYPE(Ç void fs init timer, (timer_t *tp) DD; 
21385 


21386 /* cdprobe.c */ 
21387 | PROTOTYPE( int cdprobe, (void) Jo 
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HHHHHHHHHHHHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH HHHH O O O O O DO OO OD O O 
servers/fs/glo.h 
DO ssa Do O o a O HEHHEHE HHHH HHHH HHHH HHH HHHH HHHH H+ O O O DD HHH O O DO OO OO O O 


21400 /* EXTERN deve ser extern, exceto para o arquivo de tabela */ 

21401 #ifdef TABLE 

21402 #undef EXTERN 

21403 #define EXTERN 

21404 #endif 

21405 

21406 /* variáveis globais do Sistema de Arquivos */ 

21407 EXTERN struct fproc *fp;  /* ponteiro para estrutura fproc do processo que fez a chamada */ 


21408 EXTERN int super_user; /* 1 se o processo que fez a chamada é superusuário, senão O */ 
21409 EXTERN int susp_count; /* número de procs suspensos no pipe */ 

21410 EXTERN int nr_locks; /* número de travas correntemente em vigor */ 

21411 EXTERN int reviving; /* número de processos de pipe a serem reanimados */ 

21412 EXTERN off t rdahedpos; /* posição para leitura antecipada */ 

21413 EXTERN struct inode *rdahed inode; /* ponteiro para i-node para leitura antecipada */ 
21414 EXTERN Dev t root dev; /* número do dispositivo-raiz */ 

21415 EXTERN time t boottime; /* tempo, em segundos, na inicialização do sistema */ 

21416 

21417 /* Os parâmetros da chamada são mantidos aqui. */ 

21418 EXTERN message m in; /* a mensagem de entrada em si */ 

21419 EXTERN message m out; /* a mensagem de saída usada para resposta */ 

21420 EXTERN int who; /* número do processo que fez a chamada */ 

21421 EXTERN int call nr; /* número da chamada de sistema */ 


21422 EXTERN char user path[PATH MAX];/* armazenamento para nome de caminho do usuário */ 
21423 
21424 /* Variáveis retornam resultados para o processo que fez a chamada. */ 


21425 EXTERN int err code; /* armazenamento temporário para número de erro */ 
21426 EXTERN int rdwt err; /* status da última requisição de e/s de disco */ 
21427 


21428 /* Dados inicializados em outro lugar. */ 

21429 extern PROTOTYPE (int (*call vec[]), (void) ); /* tabela de chamads de sis */ 

21430 extern char dot1[2]; /* dotl (&dot1[0]) e dot2 (&dot2[0]) têm significado */ 

21431 extern char dot2[3]; /* especial para search dir: nenhuma verificação de permissão de 
acesso. */ 


HHHEHHHHHHHHH O EO RO DO SAD DO HHHH HHHH HHHH HH HHHH HHHH HHHH H+H O O DO OO OO O O O 
servers/fs/fproc.h 
DO ssa Do o o A O DO H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH O DD HHH O DO OO OO O O 


21500 /* Esta é a informação por processo. Uma entrada é reservada para cada processo 


21501 * em potencial. Assim, NR PROCS deve ser o mesmo que no núcleo. Não é 

21502 * possível nem mesmo necessário informar quando uma entrada está livre aqui. 
21503 */ 

21504 EXTERN struct fproc { 

21505 mode_t fp_umask; /* máscara configurada pela chamada de sistema umask */ 
21506 struct inode *fp workdir;/* ponteiro para i-node do diretório de trabalho */ 
21507 struct inode *fp rootdir;/* ponteiro para diretório-raiz corrente (veja chroot) */ 
21508 struct filp *fp filp[OPEN MAX];/* a tabela de descritores de arquivo */ 

21509 uid t fp realuid; /* id real de usuário */ 

21510 uid t fp effuid; /* id efetivo de usuário */ 

21511 gid t fp realgid; /* id real de grupo */ 

21512 gid t fp effgid; /* id efetivo de grupo */ 

21513 dev t fp tty; /* principal/secundário de tty de controle */ 


21514 int fp fd; /* área para salvar fd se Teiturat/escrita não puder terminar */ 
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21515 char *fp buffer; /* área para salvar buffer se leitura/escrita não puder terminar */ 
21516 int fp nbytes; /* área para salvar bytes se leitura/escrita não puder terminar */ 
21517 int fp cum io partial;/* Qtde parcial de bytes se E/S não puder terminar */ 


21518 char fp suspended; 

21519 char fp revived; 

21520 char fp task; 

21521 char fp sesldr; 

21522 pidt fppid; 

21523 long fp cloexec; 

21524 3 fproc[NR PROCS]; 

21525 

21526 /* Valores de campo. */ 

21527  &define NOT SUSPENDED 0 

21528 define SUSPENDED 1 

21529 &define NOT REVIVING 0 
1 
0 


/* configurado para indicar processo preso */ 

/* configurado para indicar processo sendo reanimado */ 
/* em qual tarefa o proc está suspenso */ 

/* true se o proc for líder de sessão */ 

/* id de processo */ 

/* mapa de bits para Tabela 6-2 do POSIX FD CLOEXEC */ 


processo não está suspenso em pipe nem em tarefa */ 
processo está suspenso em pipe ou em tarefa */ 
processo não está sendo reanimado */ 

processo está sendo reanimado da suspensão */ 

* entrada de processo livre */ 


oooo 


21530 &define REVIVING 
21531 &define PID FREE 
21532 

21533 /* Verifica se o número do processo é aceitável - inclui processos de sistema. */ 
21534 #define isokprocnr(n) (Cunsigned) (C(n)+NR TASKS) < NR PROCS + NR TASKS) 

21535 


Eae 


HHHHHEHHHHHHH HH HHH HHHH HHHH HHHH HHH HHHH O HH HHHH O DA H+ O O DO OO OO O O 
servers/fs/buf.h 


HHHH HHHH HHHH HHHH HHHH HH HHHH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH HHHH HHHH 


21600 /* Cache de buffer (bloco). Para adquirir um bloco, uma rotina chama get block(), 


21601 * informando qual bloco deseja. Então, o bloco é visto como "em uso" 

21602 * e tem seu campo 'b count” incrementado. Todos os blocos que não estão 

21603 * em uso são encadeados em uma lista LRU, com "front" apontando 

21604 * para o bloco usado menos recentemente e "rear" para o bloco usado mais 

21605 * recentemente. Um encadeamento inverso, usando o campo b prev, também é mantido. 
21606 * A utilização de LRU é medida pelo tempo que put block() termina. O segundo 
21607 * parâmetro de put block() pode violar a ordem da LRU e colocar um bloco no 

21608 * início da lista, se ele provavelmente não for necessário logo. Se um bloco 
21609 * é modificado, a rotina de modificação deve configurar b dirt como DIRTY, para que o 
21610 * bloco finalmente seja reescrito no disco. 

21611 */ 

21612 

21613 #include <sys/dir.h> /* precisa de estrutura direta */ 

21614 #include <dirent.h> 

21615 


21616 EXTERN struct buf 1 
21617 /* Parte de dados do buffer. */ 
21618 union 1 


21619 char b data[MAX BLOCK SIZE]; /* dados de usuário normais */ 
21620 /* bloco de diretório */ 

21621 struct direct b dir[NR DIR ENTRIES(MAX BLOCK SIZE)]; 

21622 /* bloco indireto do V1 */ 

21623 zonel t b vil ind[V1 INDIRECTS]; 

21624 /* bloco indireto do V2 */ 

21625 zone t b v2 ind[V2 INDIRECTS(MAX BLOCK SIZE)]; 

21626 /* bloco de i-node do V1 */ 

21627 di inode b v1 ino[V1 INODES PER BLOCK]; 


21628 /* bloco de i-node do V2 */ 
21629 d2 inode b v2 ino[V2 INODES PER BLOCK(MAX BLOCK SIZE)]; 
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21630 
21631 
21632 
21633 
21634 
21635 
21636 
21637 
21638 
21639 
21640 
21641 
21642 
21643 
21644 
21645 
21646 
21647 
21648 
21649 
21650 
21651 
21652 
21653 
21654 
21655 
21656 
21657 
21658 
21659 
21660 
21661 
21662 
21663 
21664 
21665 
21666 
21667 
21668 
21669 
21670 
21671 
21672 
21673 
21674 


/* bloco de mapa de bits */ 
bitchunk t b bitmap[FS BITMAP CHUNKS(MAX BLOCK SIZE)]; 


} b; 

/* Parte do cabeçalho do buffer. */ 

struct buf *b_next; /* usado para vincular todos os bufs livres em um encadeamento */ 
struct buf *b_prev; /* usado para vincular todos os bufs livres de outra maneira */ 
struct buf *b_hash; /* usado para vincular bufs em encadeamentos hash */ 

block t b blocknr; /* número de bloco de seu dispositivo (secundário) */ 

dev t b dev; /* dispositivo principal | secundário onde o bloco reside */ 

char b dirt; /* CLEAN ou DIRTY */ 

char b count; /* número de usuários desse buffer */ 


) buf [NR BUFS]; 


/* Um bloco está livre se b dev == NO DEV. */ 


tdefine 


NIL BUF ((struct buf *) 0) /* indica ausência de um buffer */ 


/* Essas defs tornam possível usar em bp->b data, em vez de bp->b.b data */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


b data b.b data 

b dir b.b dir 
bvl ind b.b vil ind 
bv2 ind b.b v2 ind 
bvlino b.b vil ino 
bv2 ino b.b v2 ino 
b bitmap b.b bitmap 


EXTERN struct buf *buf hash[NR BUF HASH]; /* a tabela hash de buffer */ 


EXTERN struct buf *front; /* aponta para o bloco livre usado menos recentemente */ 
EXTERN struct buf “rear; /* aponta para o bloco livre usado mais recentemente */ 
EXTERN int bufs in use; /* número de bufs correntemente em uso (não na lista de Tivres)*/ 


/* Quando um bloco é liberado, o tipo de utilização é passado para put block. */ 


tdefine 
tdefine 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


tdefine 


WRITE IMMED 0100 /* o bloco deve ser escrito no disco agora */ 

ONE SHOT 0200 /* configura se o bloco não será necessário em breve */ 

INODE BLOCK 0 /* bloco de i-node */ 

DIRECTORY BLOCK 1 /* bloco de diretório */ 
INDIRECT BLOCK 2 /* bloco de ponteiro */ 

MAP BLOCK 3 /* mapa de bits */ 

FULL DATA BLOCK 5 /* dados totalmente usados */ 
PARTIAL DATA BLOCK 6 /* dados parcialmente usados */ 
HASH MASK (NR BUF HASH - 1) /* máscara para hash de números de bloco */ 


HEHEHEHEH HEHH HHHH HH HH H+H H+ HH HEHH HHHH H+H HH HHHH H+H HHHH +++ 
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HEHEHEHEHE HHHH HHHH HHHH HH HH HH HHHH HHHH HHHH H+H H+H HHH HHHH ++ 


21700 
21701 
21702 
21703 
21704 
21705 
21706 
21707 
21708 
21709 


/* Esta é a tabela filp. Ela é uma intermediária entre descritores de arquivo e 
* i-nodes. Uma entrada está livre se filp count == 0. 
*/ 
EXTERN struct filp { 
mode_t filp_mode; /* bits RW, informando como o arquivo é aberto */ 
int filp_flags; /* flags de abertura e fcntl */ 
int filp count; /* quantos descritores de arquivo compartilham essa entrada?*/ 


struct inode *filp ino; /* ponteiro para o i-node */ 


off t 


filp pos; /* posição do arquivo */ 
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21710 

21711 /* os campos a seguir são para select() e pertencem ao código de select() genérico 
21712 * (isto é, o código de select() específico para o tipo fd não pode mexer neles). 

21713 */ 

21714 int filp selectors; /* seleciona (com select()) processos que bloqueiam nesse 
fd */ 

21715 int filp select ops; /* interessado nessas operações SEL * */ 

21716 

21717 /* os seguintes são para select() específico do tipo fd */ 


21718 int filp pipe select ops; 
21719 } filpINR FILPS]; 


21720 

21721 &define FILP CLOSED 0 /* filp mode: dispositivo associado fechado */ 

21722 

21723 #define NIL FILP (struct filp *) O /* indica ausência de uma entrada de filp */ 


HHHHHEHHHHHHHH HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HH O O O DO OO O O 
servers/fs/lock.h 
DO spa Do O o a O O HHHH HHHH HHHH HHHH HHH HHHH HHHH HHHH HHHH H+ O O O DD OO O O O 


21800 /* Esta é a tabela de travas de arquivo. Assim como a tabeça filp, ela aponta para 


21801 * a tabela de i-nodes, contudo, neste caso para obter travas consultivas. 

21802 */ 

21803 EXTERN struct file_lock { 

21804 short lock_type; /* F_RDLOCK ou F WRLOCK; O = entrada não utilizada */ 
21805 pid t lock pid; /* pid do processo que mantém a trava */ 

21806 struct inode *lock inode; /* ponteiro para o i-node travado */ 

21807 off t lock first; /* deslocamento do primeiro byte travado */ 

21808 off t lock last; /* deslocamento do último byte travado */ 


21809 ) file lTock[NR LOCKS]; 
DO spa oo O O O O O HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O DO O O O DS 
servers/fs/inode.h 


HEHEHEHEH HEHH HHHH HHH HH H+H HH HH HHH H+H HHHH H+H HH HHHH H+H H+ HHH HHHH H+HHH+HH+H+H+H+H+H+H+H+H+ 


21900 /* Tabela de i-nodes. Esta tabela contém os i-nodes que estão correntemente em uso. Em alguns 


21901 * casos, eles foram abertos por uma chamada de sistema open() ou creat(), em outros 
21902 * casos, o próprio sistema de arquivos precisa do i-node por um motivo ou outro, 
21903 * como no caso da pesquisa de um diretório para encontrar um nome de caminho. 

21904 * A primeira parte da estrutura contém campos que estão presentes no 

21905 * disco; a segunda parte contém campos que não estão presentes no disco. 

21906 * A parte de i-node do disco também é declarada em "type.h" como 'd1 inode” para 
21907 * sistemas de arquivos V1 e "d2 inode' para sistemas de arquivos V2. 

21908 xy 

21909 

21910 EXTERN struct inode { 

21911 mode_t i_mode; /* tipo de arquivo, proteção etc. */ 

21912 nlink t à nlinks; /* quantos vínculos para esse arquivo */ 

21913 uid t i uid; /* id de usuário do proprietário do arquivo */ 

21914 gidtigid; /* número do grupo */ 

21915 off t i size; /* tamanho do arquivo corrente em bytes */ 

21916 time t i atime; /* tempo do último acesso (somente para o V2) */ 

21917 time t i mtime; /* quando os dados do arquivo foram alterados pela última vez */ 
21918 time t i ctime; /* quando o próprio i-node foi alterado (somente para o V2)*/ 


21919 zone t i zone[V2 NR TZONES]; /* números de zona para direto, ind e ind dupl */ 
21920 


21921 /* Os itens a seguir não estão presentes no disco. */ 
21922 dev t i dev; /* em qual dispositivo o i-node está */ 
21923 ino t 7 num; /* número do i-node em seu dispositivo (secundário) */ 


21924 int i count; /* nr. de vezes que o i-node foi usado; O = que a entrada está livre */ 
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21925 
21926 
21927 
21928 
21929 
21930 
21931 
21932 
21933 
21934 
21935 
21936 
21937 
21938 
21939 
21940 
21941 
21942 
21943 


int io 
int io 


ndzones; 
nindirs; 


struct super block *i sp; 
char 1 dirt; 
char i pipe; 
char i mount; 
char 1 seek; 
char i update; 

+ inode[NR INODES]; 


tdefine NIL INODE (struct inode *) O 


Ed RR 


número de zonas diretas (Vx NR DZONES) */ 
número de zonas indiretas por bloco indireto */ 


* ponteiro para superbloco do dispositivo do i-node */ 
* CLEAN ou DIRTY */ 


configura como I PIPE se for pipe */ 
este bit é ativado se o arquivo for montado */ 


* ativa em LSEEK, desativa em READ/WRITE */ 


os bits ATIME, CTIME e MTIME estão aqui */ 


/* indica ausência de entrada de i-node */ 


/* Valores de campo. Note que CLEAN e DIRTY são definidos em "const.h"” */ 
/* à pipe é NO PIPE se o i-node não é um pipe */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


NO PIPE 
I PIPE 
NO MOUNT 
I MOUNT 
NO SEEK 
ISEEK 


nRHOHOHO 


/* 
/* 


i_pipe é I_PIPE se o i-node é um pipe */ 
i_mount é NO_MOUNT se o arquivo não estiver montado */ 


/* à mount é I MOUNT se o arquivo estiver montado */ 
/* à seek = NO SEEK se a última operação não foi SEEK */ 


/* 


i_seek = ISEEK se a última op foi SEEK */ 


HEHEHEHEHE HH HHHH HHHH HHHH HH HHH H+H HHHH HHHH ++ 


servers/fs/param.h 


HEHEHEHEH HHHH HHHH HHH HH HH H+ HH HHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH H+ HH HH+H+H+H+H+H+H+H+H+ 


22000 
22001 
22002 
22003 
22004 
22005 
22006 
22007 
22008 
22009 
22010 
22011 
22012 
22013 
22014 
22015 
22016 
22017 
22018 
22019 
22020 
22021 
22022 
22023 
22024 
22025 
22026 
22027 
22028 
22029 
22030 
22031 
22032 
22033 
22034 


/* Os nomes a seguir são sinônimos para as variáveis na mensagem de entrada. */ 


tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 
tdefine 


acc time 
addr 

buffer 
child 

co mode 

eff grp id 
eff user id 
erki 

fd 

fd2 

ioflags 
group 

real grp id 
Is fd 

mk mode 

mk zO 

mode 

c mode 

c name 

name 

namel 

name2 

name Tength 
namel length 
name2 length 
nbytes 
owner 
parent 
pathname 
pid 

pro 

ctl req 
driver nr 
dev nr 


m2 11 
mi i3 
mi pi 
mi i2 
mi il 
mi i3 
mi i3 
mi pl 
mi il 
mi i2 
mi 13 
mi 13 
mi i2 
m2 il 
mi i2 
ml i3 
m3 12 
mi i3 
mi pl 
m3 pl 
mi pl 
mi p2 
m3 11 
mi il 
mi i2 
mi i2 
mi i2 
mi il 
m3 cal 
mi i3 
mi il 
m4 11 
m4 12 
m4 13 
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22035 
22036 
22037 
22038 
22039 
22040 
22041 
22042 
22043 
22044 
22045 
22046 
22047 
22048 
22049 
22050 
22051 
22052 
22053 
22054 
22055 
22056 
22057 
22058 
22059 
22060 
22061 
22062 
22063 


tdefine dev style 
ádefine rd only 
gdefine real user id 
tdefine request 
tdefine sig 

tdefine slotl 
#define tp 

gdefine utime actime 
#define utime modtime 
#define utime file 
tdefine utime length 
#define utime strlen 
tdefine whence 
tdefine svrctl req 
tdefine svrctl argp 
tdefine pm stime 
tdefine info what 
tdefine info where 


m4 14 
mi 13 
mi i2 
mi i2 
mi i2 
mi il 
m2 11 
m2 11 
m2 12 
m2 pl 
m2 il 
m2 i2 
m2 i2 
m2 il 
m2 pl 
mi il 
mi il 
mi pl 


/* Os nomes a seguir são sinônimos para as variáveis na mensagem de saída. */ 
m type 


tdefine reply type 
tdefine reply 11 
tdefine reply il 
ádefine reply i2 
tdefine reply t1 
tdefine reply t2 
“define reply t3 
ádefine reply t4 
“define reply t5 


m2 11 
mi il 
mi i2 
m4 11 
m4 12 
m4 13 
m4 14 
m4 15 


HEHEHEHEH HHHH HHHH HHH HH H+H H+ HH HH H+H HHHH H+H HH HHHH H+H HHHH HHHH H+HHH+HH+H+H+H+H+H+H+H+H+ 
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HHHHHHHHH HHHH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH H+H H+H H+H HHHH H+ HH HHHH HHHH 


22100 
22101 
22102 
22103 
22104 
22105 
22106 
22107 
22108 
22109 
22110 
22111 
22112 
22113 
22114 
22115 
22116 
22117 
22118 
22119 
22120 
22121 
22122 
22123 
22124 


/* Tabela de superblocos. O sistema de arquivos raiz e todo sistema de arquivos montado 


* tem uma entrada aqui. A entrada contém informações sobre os tamanhos dos mapas 
de bits e i-nodes. O campo s ninodes fornece o número de i-nodes disponíveis 


* para arquivos e diretórios, incluindo o diretório-raiz. O i-node 0 está 


* 


* 


no disco, mas não é usado. Assim, s ninodes = 4 significa que 5 bits serão 
usados no mapa de bits, bit O, que é sempre 1 e não é usado e os bits 1-4 


* para arquivos e diretórios. O layout do disco é: 


ii Item número de blocos 


superbloco 
E mapa de i-nodes 


* zonas de dados 


*/ 


EXTERN struct super bl 
ino_t s_ninodes; 
zonel_t s_nzones; 
short s_imap_blocks; 
short s_zmap_blocks; 


1 


bloco de inicialização 1 


(1kB de deslocamento) 


s imap blocks 
* mapa de zonas s zmap blocks 


i-nodes (s ninodes + "i-nodes por bloco” - 1)/"i-nodes por bloco” 
ki não usado o que for necessário para preencher a zona corrente 


(s zones - s firstdatazone) << s log zone size 


ock { 


Uma entrada de super_block está livre se s_dev == NO_DEV. 


/* nr. de i-nodes utilizáveis no dispositivo secundário */ 

/* tamanho total do dispositivo, incluindo mapas de bits etc */ 
/* nr. de blocos usados pelo mapa de bits de i-node */ 

/* nr. de blocos usados por mapa de bits de zona */ 


Apêndice B e O CóbiGo-FONTE DO MINIX 877 


22125 
22126 
22127 
22128 
22129 
22130 
22131 
22132 
22133 
22134 
22135 
22136 
22137 
22138 
22139 
22140 
22141 
22142 
22143 
22144 
22145 
22146 
22147 
22148 
22149 
22150 
22151 
22152 
22153 
22154 
22155 
22156 
22157 
22158 


zonel t s firstdatazone; 
short s log zone size; 
short s pad; 

off t s max size; 

zone t s zones; 

short s magic; 


número da primeira zona de dados */ 

log2 de blocos/zona */ 

* tenta evitar o preenchimento dependente de compilador */ 
* tamanho de arquivo máximo nesse dispositivo */ 

número de zonas (substitui s nzones no V2) */ 

número mágico para reconhecer superblocos */ 


Eis eee 


/* Os itens a seguir são válidos no disco apenas para V3 e acima */ 


/* O tamanho do bloco em bytes. Mínimo MIN BLOCK SIZE. SECTOR SIZE 
* múltiplo. Se for sistema de arquivos V1 ou V2, isso deve ser 
* inicializado como STATIC BLOCK SIZE. Máximo MAX BLOCK SIZE. 


*/ 

short s pad2; /* tenta evitar preenchimento dependente do compilador */ 
unsigned short s block size; /* tamanho do bloco em bytes. */ 

char s disk version; /* sub-versão do formato do sistema de arquivos */ 


/* Os itens a seguir são usados somente quando o superbloco está na memória. */ 

struct inode *s isup; * i-node do diretório-raiz de sistema de arq montado */ 

struct inode *s imount; * j-node montado */ 

unsigned s inodes per block; calculado previamente a partir do número mágico */ 

dev t s dev; de quem é este superbloco? */ 

int s rd only; 1 se FS montado somente para leitura */ 

int s native; * 1 se não FS for com byte trocado */ 

int s version; versão do FS, zero significa mágico errado */ 

int s ndzones; número de zonas diretas em um i-node */ 

int s nindirs; número de zonas indiretas por bloco indireto */ 

bit ts isearch; * os i-nodes abaixo deste número de bit estão em uso */ 

bit ts zsearch; * todas as zonas abaixo deste número de bit estão em uso */ 
) super block[NR SUPERS]; 


dei Ed 


#define NIL SUPER (struct super block *) O 
#define IMAP 0 /* operando no mapa de bits do i-node */ 
#define ZMAP 1 /* operando no mapa de bits de zona */ 


AAA ++ 


servers/fs/table.c 


HEHEHEHEH HEHH HHHH HHHH H+H H+ HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH H+H+HH+HH+H+H+H+H+H+H+H+H+ 


22200 
22201 
22202 
22203 
22204 
22205 
22206 
22207 
22208 
22209 
22210 
22211 
22212 
22213 
22214 
22215 
22216 
22217 
22218 
22219 


/* Este arquivo contém a tabela usada para fazer o mapeamento de números de chamada de 
* sistema nas rotinas que as executam. 


*/ 
gdefine TABLE 


ginclude "fs.h" 

tinclude <minix/calinr.h> 
tinclude <minix/com.h> 
tinclude "buf.h" 

ginclude "file.h" 
ginclude "fproc.h" 
tinclude "inode.h" 
tinclude "Tock.h" 
ginclude "super.h" 


PUBLIC | PROTOTYPE (int (*call vecl]), (void) ) = { 
no sys, /* O = não utilizado */ 
do exit, /* 1 = exit */ 
do fork, /* 2 = fork */ 
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22220 
22221 
22222 
22223 
22224 
22225 
22226 
22227 
22228 
22229 
22230 
22231 
22232 
22233 
22234 
22235 
22236 
22237 
22238 
22239 
22240 
22241 
22242 
22243 
22244 
22245 
22246 
22247 
22248 
22249 
22250 
22251 
22252 
22253 
22254 
22255 
22256 
22257 
22258 
22259 
22260 
22261 
22262 
22263 
22264 
22265 
22266 
22267 
22268 
22269 
22270 
22271 
22272 
22273 
22274 
22275 
22276 
22277 
22278 
22279 


do read, 
do write, 
do open, 
do close, 
no sys, 
do creat, 
do link, 
do unlink, 
no sys, 
do chdir, 
no sys, 
do mknod, 
do chmod, 
do chown, 
no sys, 
do stat, 
do Tseek, 
no sys, 
do mount, 
do umount, 
do set, 
no sys, 
do stime, 
no sys, 
no sys, 
do fstat, 
no sys, 
do utime, 
no sys, 
no sys, 
do access, 
no sys, 
no sys, 
do sync, 
no sys, 
do rename, 
do mkdir, 
do unlink, 
do dup, 
do pipe, 
no sys, 
no sys, 
no sys, 
do set, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
do ioctl, 
do fentl, 
no sys, 
no sys, 
no sys, 
do exec, 
do umask, 
do chroot, 
do setsid, 


e 
»o o 


+o ox 


%* 


+o % 


%* 


OE 


%* 


+o % 


* 


a a A N NNNnnn NaN NNN NNN 


= read */ 
write */ 
open */ 
close */ 
wait */ 
creat */ 
link */ 
unlink */ 
waitpid */ 
chdir */ 
time */ 
mknod */ 
chmod */ 
chown */ 
break */ 
stat */ 
Tseek */ 
getpid */ 
mount */ 
umount  */ 
setuid  */ 
getuid */ 
stime */ 
ptrace */ 
alarm */ 
fstat * 
pause */ 
utime */ 
Cstty)  */ 
Cgtty) */ 
access */ 
(nice) */ 
(ftime) */ 
sync */ 
kill */ 
rename */ 
mkdir */ 
rmdir */ 
dup 74 
pipe 2/ 
times */ 
(prof) */ 
não utilizado * 
setgid */ 
getgid */ 
Csignal)*/ 
não utilizado 
não utilizado 
(acct) */ 
(phys) */ 
Clock) */ 
ioctl */ 
fcntl */ 
(mpx) zy 


não utilizado * 


não utilizado 
execve */ 


umask */ 
chroot */ 
= setsid */ 


i 


*/ 
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22280 
22281 
22282 
22283 
22284 
22285 
22286 
22287 
22288 
22289 
22290 
22291 
22292 
22293 
22294 
22295 
22296 
22297 
22298 
22299 
22300 
22301 
22302 
22303 
22304 
22305 
22306 
22307 
22308 
22309 
22310 
22311 
22312 
22313 


En Sa SA DO O OD H EH HH H+ HHH HHHH HEHH HH HHH HHHH HHHH HHHH HHHH H+ HH HHHH DO O DO O O RO 
servers/fs/cache.c 
En Sa SAD O O o HH HHHH HHHH HHHH H HH HHEH HHHH HHHH HHHH HHH O O DO SDS RODO RO O O OO O O RO 


22400 
22401 
22402 
22403 
22404 
22405 
22406 
22407 
22408 
22409 
22410 
22411 
22412 
22413 
22414 
22415 
22416 
22417 
22418 
22419 


}; 


/* Isso não deve falhar com "tamanho do array é negativo": */ 
extern int dummy[sizeof(call vec) == NCALLS * sizeof(call vec[0]) ? 1: 


/* O sistema de arquivos mantém uma cache de buffer para reduzir o número de acessos 
* a disco necessários. Quando uma leitura ou escrita no disco é feita, primeiro é 
realizada uma verificação para ver se o bloco está na cache. Este arquivo gerencia a 


* cache 


no sys, 


no sys, 
do unpause, 
no sys, 
do revive, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
no sys, 
do reboot, 
do svrctl, 


no sys, 
do getsysinfo, 
no sys, 

do devctl, 

do fstatfs, 

no sys, 

no sys, 

do select, 

do fchdir, 

do fsync, 

no sys, 

no sys, 

no sys, 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


getpgrp */ 


REVIVE */ 


= TASK_REPLY 
= não utilizado * 
= não utilizado */ 


si */ 


= sigsuspend */ 


sigpending */ 


= sigprocmask */ 


sigreturn */ 


= reboot */ 
= svrctl */ 


não utilizado 


= devctl */ 


fstatfs */ 


= memalloc */ 


memfree */ 


= select */ 
= fchdir */ 
= fsync */ 
= getpriority */ 
= setpriority */ 
gettimeofday */ 


* Os pontos de entrada para esse arquivo são: 
* get block: requisição para buscar um bloco para ler ou escrever da cache 


* put block: retorna um bloco solicitado anteriormente com get block 

* alloc zone: aloca uma nova zona (para aumentar o comprimento de um arquivo) 
* free zone: libera uma zona (quando um arquivo é removido) 

rw block: 1ê ou escreve um bloco do próprio disco 

invalidate: remove todos os blocos da cache em algum dispositivo 


*/ 


#include 
#include 
#include 
#include 
#include 
#include 


"Faai" 
<minix/com. h> 
"buf.h" 
"file.h" 
"fproc.h" 
"super.h" 


*/ 


= não utilizado */ 
= getsysinfo */ 
*/ 


= KSIG: sinais originados no núcleo */ 
= UNPAUSE */ 
= não utilizado */ 


*/ 


=1]; 
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22420 

22421 FORWARD PROTOTYPE( void rm Tru, (struct buf *bp) ); 

22422 

22423 [f====DD>>=DD0500 000000000 DDDODSD DDD 

22424 * get block * 

22425 FoSESSSESSSSESSSSSSDSSSSS SSIS SSD S ESSES ES DOSE DSSSD SSD SS od / 

22426 PUBLIC struct buf *get block(dev, block, only search) 

22427 register dev t dev; /* em qual dispositivo está o bloco? */ 

22428 register block t block; /* que bloco é desejado? */ 

22429 int only search; /* se for NO READ, não lê, sentão age normalmente */ 
22430 {£ 

22431 /* Verifica se o bloco solicitado está na cache de bloco. Se estiver, retorna 

22432 * um ponteiro para ele. Se não estiver, descarrega algum outro bloco e busca-o (a não ser 
22433 * que "only search” seja 1). Todos os blocos na cache que não estão sendo usados 

22434 * são vinculados em um encadeamento, com "front" apontando para o bloco usado 

22435 * menos recentemente e 'rear” apontando para o bloco usado mais recentemente. Se "only. 
22436 * search’ forl, o bloco que está sendo solicitado será totalmente sobrescrito, de modo 
22437 * que só é necessário ver se ele está na cache; se não estiver, qualquer buffer livre 
22438 * serve. Não é necessário ler realmente o bloco do disco. 

22439 * Se "only search" for PREFETCH, o bloco não precisará ser lido do disco e 

22440 * o dispositivo não será marcado no bloco, para que os processos que fizeram a chamada 
22441 * possam saber se o bloco retornado é válido. 

22442 * Além do encadeamento LRU, também existe um encadeamento hash para vincular os blocos cujos 
22443 * números terminam com as mesmas strings de bit, para possibilitar uma pesquisa rápida. 
22444 */ 

22445 

22446 int b; 

22447 register struct buf *bp, *prev ptr; 

22448 

22449 /* Pesquisa o encadeamento hash em busca de (dev, block). Do read() pode usar 

22450 * get block(NO DEV ...) para obter um bloco não nomeado para preencher com zeros 
22451 * quando alguém quiser ler de uma lacuna em um arquivo, no caso em que essa pesquisa 
22452 * não é feita 

22453 */ 

22454 if (dev != NO DEV) { 

22455 b = (int) block & HASH MASK; 

22456 bp = buf hash[b]; 

22457 while (bp != NIL BUF) { 

22458 if (bp->b blocknr == block && bp->b dev == dev) 1 

22459 /* O bloco necessário foi encontrado. */ 

22460 if Cbp->b count == 0) rm TruCbp); 

22461 bp->b count++; /* registra o fator de que o bloco está em uso */ 
22462 

22463 return(bp); 

22464 } else { 

22465 /* Este bloco não é o buscado. */ 

22466 bp = bp->b hash; /* próximo bloco no encadeamento hash */ 
22467 

22468 } 

22469 } 

22470 

22471 /* Bloco desejado não está no encadeamento disponível. Pega mais antigo (’ front’). */ 


22472 if ((bp = front) == NIL BUF) panic(. FILE ,"all buffers in use", NR_BUFS); 
22473 rm TruCbp); 

22474 

22475 /* Remove o bloco que acabou de ser obtido de seu encadeamento hash. */ 
22476 b = (Cint) bp->b blocknr & HASH MASK; 

22477 prev ptr = buf hash[b]; 

22478 if (prev ptr == bp) { 

22479 buf hash[b] = bp->b hash; 
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} else { 
/* O bloco que acabou de ser obtido não está no início de seu encadeamento hash. */ 
while (prev_ptr->b_hash != NIL_BUF) 
if (prev_ptr->b_hash == bp) { 
prev_ptr->b_hash = bp->b_hash; /* o encontrou */ 
break; 
} else { 
prev_ptr = prev_ptr->b_hash; /* continua pesquisando */ 
} 
} 


/* Se o bloco obtido estiver sujo, torna-o limpo escrevendo-o no disco. 
* Evita a histerese descarregando todos os outros blocos sujos do mesmo dispositivo. 
if (bp->b_dev != NO_DEV) { 
if (bp->b_dirt == DIRTY) flushall(bp->b_dev); 


} 

/* Preenche os parâmetros do bloco e o adiciona no encadeamento hash para onde ele vai. */ 
bp->b_dev = dev; /* preenche o número do dispositivo */ 

bp->b_blocknr = block; /* preenche o número do bloco */ 

bp->b_count++; /* registra o fato de que o bloco está sendo usado */ 


b = (int) bp->b_blocknr & HASH_MASK; 
bp->b_hash = buf_hash[b]; 
buf_hash[b] = bp; /* adiciona na lista de hash */ 


/* Obtém o bloco solicitado, a não ser que esteja pesquisando ou buscando previamente. */ 
if (dev != NO DEV) 1 
if (only search == PREFETCH) bp->b dev = NO DEV; 
else 
if (only search == NORMAL) { 
rw block(bp, READING); 
} 


return(bp); /* retorna o bloco recentemente adquirido */ 


PUBLIC void put_block(bp, block_type) 


register struct buf *bp; /* ponteiro para o buffer a ser liberado */ 
int block_type; /* INODE BLOCK, DIRECTORY BLOCK ou o que for */ 
{ 


/* Retorna um bloco para a lista de blocos disponíveis. Dependendo de "block type”, 
* ele pode ser colocado no início ou no fim do encadeamento LRU. Os blocos que provavelmente 
* serão necessários novamente em breve (por exemplo, blocos de dados parcialmente cheios) 
* ficam no final; os blocos que provavelmente não serão necessários novamente em breve 
(por exemplo, blocos de dados cheios) ficam no início. Os blocos cuja perda pode 
prejudicar a integridade do sistema de arquivos (por exemplo, blocos de i-node) são 
* escritos imediatamente no disco, se estiverem sujos. 


* 


* 


if (bp == NIL BUF) return;/* mais fácil testar aqui do que no processo que fez a chamada */ 
bp->b count--; /* há um a menos agora */ 

if Cbp->b count != 0) return; /* o bloco ainda está em uso */ 

bufs in use--; /* um buffer de bloco em uso a menos */ 


/* Coloca este bloco de volta no encadeamento LRU. Se o bit ONE SHOT estiver ativo em 
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22540 * "block type”, o bloco provamente não será necessário novamente em breve; portanto, o 
22541 * coloca no início do encadeamento LRU, onde ele será o primeiro a ser 

22542 * retirado, quando um buffer livre for necessário posteriormente. 

22543 */ 

22544 if Cbp->b dev == DEV RAM || block type & ONE SHOT) 1 

22545 /* O bloco provavelmente não será necessário rapidamente. O coloca no início do 
22546 * encadeamento. Ele será o próximo bloco a ser descarregado da cache. 
22547 */ 

22548 bp->b prev = NIL BUF; 

22549 bp->b next = front; 

22550 if (front == NIL BUF) 

22551 rear = bp; /* o encadeamento LRU estava vazio */ 

22552 else 

22553 front->b prev = bp; 

22554 front = bp; 

22555 } else { 

22556 /* O bloco provavelmente será necessário rapidamente. O coloca no fim do 
22557 * encadeamento. Ele não será descarregado da cache por um longo tempo. 
22558 gA 

22559 bp->b_prev = rear; 

22560 bp->b_next = NIL_BUF; 

22561 if (rear == NIL_BUF) 

22562 front = bp; 

22563 else 

22564 rear->b_next = bp; 

22565 rear = bp; 

22566 } 

22567 

22568 /* Alguns blocos são tão importantes (por exemplo, i-nodes, blocos indiretos) que devem 
22569 * ser escrito no disco imediatamente, para evitar que o sistema 

22570 * de arquivos seja corrompido no caso de uma falha. 

22571 */ 

22572 if (Cblock type & WRITE IMMED) && bp->b dirt==DIRTY && bp->b_dev != NO DEV) { 
22573 rw block(bp, WRITING); 

22574 } 

22575 } 

22577 

22578 

22579 

22580 PUBLIC zone_t alloc_zone(dev, z) 

22581 dev_t dev; /* dispositivo onde está a zona desejada */ 
22582 zone t Z; /* tenta alocar uma nova zona perto desta */ 
22583 1 


22584 /* Aloca uma nova zona no dispositivo indicado e retorna seu número. */ 


22586 int major, minor; 

22587 bit tb, bit; 

22588 struct super block *sp; 

22589 

22590 /* Note que a rotina alloc bit() retorna 1 para a zona mais baixa possível, 
22591 * a qual corresponde a sp->s firstdatazone. Para converter um valor 

22592 * entre o número do bit, 'b”, usado por alloc bit() e o número da zona, ’z’, 
22593 * armazenado no i-node, usa a fórmula: 

22594 * z = b + sp->s_firstdatazone - 1 

22595 * Alloc_bit() nunca retorna O, pois isso é usado para NO BIT (falha). 
22596 */ 

22597 sp = get super(dev); 

22598 


22599 /* Se z for O, pula a parte inicial do mapa que se sabe que está completamente em uso. */ 
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22600 
22601 
22602 
22603 
22604 
22605 
22606 
22607 
22608 
22609 
22610 
22611 
22612 
22613 
22614 
22615 
22616 


22618 
22619 
22620 
22621 
22622 
22623 
22624 
22625 
22626 
22627 
22628 
22629 
22630 
22631 
22632 
22633 
22634 
22635 
22636 


22638 
22639 
22640 
22641 
22642 
22643 
22644 
22645 
22646 
22647 
22648 
22649 
22650 
22651 
22652 
22653 
22654 
22655 
22656 
22657 
22658 
22659 


if (z == sp->s firstdatazone) { 
bit = sp->s zsearch; 
} else { 
bit = (bit_t) z - (sp->s_firstdatazone - 1); 
} 
b = alloc_bit(sp, ZMAP, bit); 
if (b == NO_BIT) { 
err_code = ENOSPC; 
major = (int) (sp->s_dev >> MAJOR) & BYTE; 
minor = (int) (sp->s_dev >> MINOR) & BYTE; 
printf("No space on %sdevice %d/%d\n", 
sp->s dev == root dev ? "root " : "", major, minor); 
return(NO_ZONE); 


} 
if (z == sp->s_firstdatazone) sp->s_zsearch = b; /* para a próxima vez */ 
return(sp->s firstdatazone - 1 + (zone_t) b); 

} 

/* === ¥ 
É free zone ii 
EDDD====D=D>=>>=>>>>=>>>=>>=>>=>>=>>=>>>=>=>=>>=>>=>>>>>=>>=>>=>>>>>>>>>>=>>=>>>=>>=>==>==>===> * / 

PUBLIC void free zone(dev, numb) 

dev t dev; /* dispositivo onde a zona está localizada */ 

zone t numb; /* zona a ser retornada */ 

{ 


/* Retorna uma zona. */ 


register struct super_block *sp 
bitt bit; 


/* Localiza o super_block apropriado e retorna o bit. */ 

sp = get super(dev); 

if (numb < sp->s firstdatazone || numb >= sp->s zones) return; 
bit = (bit t) (numb - (sp->s firstdatazone - 1)); 

free bit(sp, ZMAP, bit); 

if (bit < sp->s zsearch) sp->s zsearch = bit; 


} 

/* === ¥ 
é rw block ta 
EEDDS====D=D>=>>D>>>=>>=>=>=>=>>=>>>>=>>>=>>=>>=>=>>>>=>=>>=>>=>>>>=>>>>=>=>>=>>=>=>>=>>>=>=>=>===> * / 

PUBLIC void rw blockC(bp, rw flag) 

register struct buf *bp; /* ponteiro de buffer */ 

int rw flag; /* READING ou WRITING */ 

{ 


/* Lê ou escreve bloco de disco. Esta é a única rotina na qual uma E/S de disco real é 
* solicitada. Se ocorrer erro, uma msg será impressa aqui, mas o erro não será informado 
* para o processo que fez a chamada. De qualquer modo, se o erro ocorreu durante a 
* descarga de um bloco da cache, não está claro o que o processo poderia fazer a respeito. 


*/ 


int r, op; 
off t pos; 
dev t dev; 
int block size; 


block size = get block size(bp->b dev); 


if C (dev = bp->b dev) != NO DEV) 1 
pos = (off t) bp->b blocknr * block size; 
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22660 op = (rw flag == READING ? DEV READ : DEV WRITE); 

22661 r = dev iolop, dev, FS PROC NR, bp->b data, pos, block size, 0); 
22662 if (r != block size) { 

22663 if Cr >= 0) r = END OF FILE; 

22664 if Cr != END OF FILE) 

22665 printf("Unrecoverable disk error on device %d/%d, block %ld\n", 
22666 (dev>>MAJOR)&BYTE, (dev>>MINOR)&BYTE, bp->b blocknr); 
22667 bp->b dev = NO DEV; /* invalida o bloco */ 

22668 

22669 /* Informa sobre erros de leitura para as partes interessadas. */ 
22670 if (rw flag == READING) rdwt err = r; 

22671 

22672 } 

22673 

22674 bp->b_dirt = CLEAN; 

22675 } 

22677 

22678 

22679 

22680 PUBLIC void invalidate(device) 

22681 dev_t device; /* dispositivo cujos blocos devem ser expurgados */ 
22682 { 


22683 /* Remove da cache todos os blocos pertencentes a algum dispositivo. */ 


22685 register struct buf *bp; 

22686 

22687 for (bp = &buf[0]; bp < &buf[NR_BUFS]; bp++) 

22688 if (bp->b_dev == device) bp->b_dev = NO_DEV; 

22689 } 

22691 /*==== 0000 0000000 
22692 * flushall E 
22693 $ aaay 
22694 PUBLIC void flushall (dev) 

22695 dev t dev; /* dispositivo a descarregar */ 

22696 { 

22697 /* Descarrega todos os blocos sujos de um dispositivo. */ 

22698 

22699 register struct buf *bp; 

22700 static struct buf *dirty[NR BUFS]; /* static para que não esteja na pilha */ 
22701 int ndirty; 

22702 

22703 for (bp = &buf[0], ndirty = 0; bp < &buf[NR BUFS]; bp++) 

22704 if Cbp->b dirt == DIRTY && bp->b dev == dev) dirty[ndirty++] = 

22705 rw scattered(dev, dirty, ndirty, WRITING); 

22706 + 

22708 

22709 

22710 

22711 PUBLIC void rw scattered(dev, bufg, bufgsize, rw flag) 

22712 dev t dev; /* número de dispositivo principal-secundário */ 


22713 struct buf **bufq; /* ponteiro para array de buffers */ 
22714 int bufgsize; /* número de buffers */ 
22715 int rw flag; /* READING ou WRITING */ 


22716 4 
22717 /* Lê ou escreve dados dispersos de um dispositivo. */ 
22718 


22719 register struct buf *bp; 
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int gap; 

register int i; 

register iovec t *iop; 

static iovec t iovec[NR IOREQS]; /* static para que não esteja na pilha */ 
int J; r3 

int block_size; 


block_size = get_block_size(dev); 


/* (Shell) ordena buffers em b_blocknr. */ 
gap = 1; 
do 
gap = 3 * gap + 1; 
while (gap <= bufqsize); 
while (gap != 1) { 
gap /= 3; 
for (j = gap; j < bufgsize; j++) { 
for Ci = j - gap; 
i >= 0 & bufq[i]->b_blocknr > bufq[i + gap]->b_blocknr; 
i -= gap) { 
bp = bufqlil; 
bufq[i] = bufgli + gap]; 
bufq[i + gap] = bp; 


/* Configura o vetor de E/S e realiza a E/S. O resultado de dev_io será OK se tudo 


* correu bem; caso contrário, será o código de erro da primeira transferência falha. 


+ 
while (bufgsize > 0) 1 
for (j = 0, iop = iovec; j < NR IOREQS && j < bufgsize; j++, iop++) { 
bp = bufaljl; 
if (bp->b blocknr != bufg[0]->b blocknr + j) break; 
iop->iov addr = (vir bytes) bp->b data; 
iop->iov size = block size; 
} 
r = dev_io(rw_flag == WRITING ? DEV_SCATTER : DEV_GATHER, 
dev, FS PROC NR, iovec, 
Coff t) bufg[0]->b blocknr * block size, j, 0); 


/* Colhe os resultados. Dev io relata o primeiro erro que pode ter 


for Ci = 0, iop = iovec; i < j; i++, iop++) 1 
bp = bufqlil; 
if Ciop->iov size != 0) 1 
/* A transferência falhou. Um erro? Importa para nós? */ 
if Cr != OK & i == 0) É 
printf( 
"fs: I/O error on device %d/%d, block %lu\n", 
(dev>>MAJOR)&BYTE, (dev>>MINOR)&BYTE, 
bp->b_blocknr); 


bp->b_dev = NO_DEV; /* invalida o bloco */ 
} 
break; 
} 
if Crw flag == READING) { 
bp->b_dev = dev; /* valida o bloco */ 


put_block(bp, PARTIAL DATA BLOCK); 


* encontrado, mas nos preocupamos apenas se foi o primeiro bloco que falhou. 
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22780 } else { 

22781 bp->b_dirt = CLEAN; 

22782 } 

22783 } 

22784 bufq += i; 

22785 bufqsize -= i; 

22786 if Crw flag == READING) { 

22787 /* Não se preocupa em ler mais do que o dispositivo está querendo 

22788 * fornecer neste momento. Não se esqueça de liberar esses extras. 

22789 RA 

22790 while (bufgsize > 0) 1 

22791 put blockC*bufq++, PARTIAL DATA BLOCK); 

22792 bufgsize--; 

22793 3 

22794 } 

22795 if Crw flag == WRITING && i == 0) { 

22796 /* Não estamos fazendo progresso; isso significa que podemos continuar no laço. 
22797 * Os buffers permanecerão sujos, se não forem escritos. Os buffers serão perdidos 
22798 * se forem invalidados (com invalidate()) ou removidos da LRU enquanto estiverem 
22799 * sujos. Isso é melhor do que manter por perto blocos não graváveis para sempre.. 
22800 */ 

22801 break; 

22802 } 

22803 } 

22804 } 


22806 — /Z==================>=======>==>===>>=>==>=>=>=>>=>>=>>=>==>=>=>>>=>>=>>>=>=>=>>=>====>==>===> ¥ 
22807 $ rm Tru * 
22808 É Ý / 
22809 PRIVATE void rm TruCbp) 

22810 struct buf *bp; 


22811 { 

22812 /* Remove um bloco de seu encadeamento LRU. */ 

22813 struct buf “next ptr, *prev ptr; 

22814 

22815 bufs in use++; 

22816 next ptr = bp->b next; /* sucessor no encadeamento LRU */ 

22817 prev ptr = bp->b prev; /* predecessor no encadeamento LRU */ 

22818 if (prev ptr != NIL BUF) 

22819 prev ptr->b next = next ptr; 

22820 else 

22821 front = next ptr; /* este bloco estava no início do encadeamento */ 
22822 

22823 if (next ptr != NIL BUF) 

22824 next ptr->b prev = prev ptr; 

22825 else 

22826 rear = prev ptr; /* este bloco estava no fim do encadeamento */ 
22827 3 


DO spa Do O o O HHHH +H HHHH HHHH HHHH HHH H+H HH HHHH HHHH O DD O O O O DD OO OO O O O 
servers/fs/inode.c 
DO soa Do o O O O H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O O DO O O O O 


22900 /* Este arquivo gerencia a tabela de i-nodes. Existem funções para alocar e 


22901 * liberar i-nodes, adquiri-los, apagá-los e liberá-los, e para lê-los e escrevê-los 
22902 * no disco. 
22903 x 


22904 * Os pontos de entrada para este arquivo são 
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22905 
22906 
22907 
22908 
22909 
22910 
22911 
22912 
22913 
22914 
22915 
22916 
22917 
22918 
22919 
22920 
22921 
22922 
22923 
22924 
22925 
22926 
22927 
22928 
22929 
22930 
22931 
22932 
22933 
22934 
22935 
22936 
22937 
22938 
22939 
22940 
22941 
22942 
22943 
22944 
22945 
22946 
22947 
22948 
22949 
22950 
22951 
22952 
22953 
22954 
22955 
22956 
22957 
22958 
22959 
22960 
22961 
22962 
22963 
22964 


get inode: pesquisa a tabela de i-nodes em busca de determinado i-node; se não 
estiver lá, o lê 

* put inode: indica que um i-node não é mais necessário na memória 

* alloc inode: aloca um novo i-node não utilizado 

*  wipe inode: apaga alguns campos de um i-node recentemente alocado 

* free inode: marca um i-node como disponível para um novo arquivo 

* update times: atualiza atime, ctime e mtime 

* rw inode: 1ê um bloco do disco e extrai um i-node ou a escrita correspondente 

* old icopy: copia na/da estrutura de i-node no núcleo e de i-node do disco (V1.x) 
new icopy: copia na/da estrutura de i-node no núcleo e de i-node do disco (V2.x) 

* — dup inode: indica que alguém está usando uma entrada da tabela de i-nodes 


*/. 


#include "fs.h" 
#include "buf.h" 
#include "file.h" 
#include "fproc.h" 
#include "inode.h" 
#include "super.h" 


FORWARD | PROTOTYPE( void old_icopy, (struct inode *rip, dl inode *dip, 

int direction, int norm)); 
FORWARD | PROTOTYPE( void new icopy, (struct inode *rip, d2 inode *dip, 

int direction, int norm)); 


J nn 
* get inode * 
X D= * / 
PUBLIC struct inode *get inode(dev, numb) 
dev t dev; /* dispositivo no qual reside o i-node */ 
int numb; /* número do i-node (ANSI: não pode ser unshort) */ 
{ 
/* Localiza uma entrada na tabela de i-nodes, carrega nela o i-node especificado e 
* retorna um ponteiro para a entrada. Se 'dev” == NO DEV, apenas retorna uma entrada livre. 
*/ 


register struct inode “rip, *xp; 


/* Pesquisa a tabela de i-nodes em busca de (dev, numb) e de uma entrada livre. */ 

xp = NIL INODE; 

for (rip = &inode[0]; rip < &inode[NR INODES]; rip++) { 

if Crip->i count > 0) { /* verifica apenas as entradas usadas por (dev, numb) */ 
if Crip->i dev == dev && rip->i num == numb) { 

/* Este é o i-node que estamos procurando. */ 
rip->i. count++; 
returnCrip); /* (dev, numb) encontrado */ 


xp = rip; /* lembra desta entrada livre mais tarde */ 


/* O i-node que queremos não está correntemente em uso. Encontramos uma entrada livre? */ 
if (xp == NIL INODE) 1 /* tabela de i-nodes completamente cheia */ 

err code = ENFILE; 

return(NIL INODE); 
} 


/* Uma entrada de i-node livre foi localizada. Carrega o i-node nela. */ 
xp->i_dev = dev; 
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22965 xp->i_num = numb; 
22966 xp->i_count = 1; 


22967 if (dev != NO DEV) rw inode(xp, READING); /* obtém i-node do disco */ 

22968 xp->i update = 0; /* todos os tempos estão inicialmente atualizados */ 
22969 

22970 return(xp); 

22971 + 

22973 [*======"D>=2D20=>505 5500055000 DDSDSDDSDS DESDE see e 
22974 * put inode * 
22975 ÉDER / 
22976 PUBLIC void put inode(rip) 

22977 register struct inode *rip; /* ponteiro para o i-node a ser liberado */ 

22978 | 

22979 /* O processo que fez a chamada não está mais usando este i-node. Se mais ninguém o 
22980 * estiver usando escreva-o de volta no disco, imediatamente. Se ele não tiver vínculos, 
22981 * trunca-o e retorna-o para o pool de i-nodes disponíveis. 

22982 */ 

22983 

22984 if Crip == NIL INODE) return; /* testar aqui é mais fácil do que no proc.chamador */ 
22985 if (--rip->i count == 0) { /* i count == 0 significa que ninguém o está usando agora */ 
22986 if Crip->i nlinks == 0) { 

22987 /* à nlinks == 0 significa liberar o i-node. */ 

22988 truncate(rip); /* retorna todos os blocos do disco */ 

22989 rip->i mode = I NOT ALLOC; /* limpa o campo I TYPE */ 

22990 rip->i dirt = DIRTY; 

22991 free inode(rip->i dev, rip->i num); 

22992 } else { 

22993 if Crip->i pipe == I_PIPE) truncate(rip); 

22994 } 

22995 rip->i_pipe = NO_PIPE; /* sempre deve ser limpo */ 

22996 if Crip->i dirt == DIRTY) rw_inode(rip, WRITING); 

22997 } 

22998 } 

23000 /* === 
23001 F alloc_inode * 
23002 fOSESSSDSSSSESSSSSSDSSSSSSSSSSSSDSSDS SED SSS DOSES SSD E SSD SE e / 
23003 PUBLIC struct inode *alloc inode(dev t dev, mode t bits) 

23004 1 


23005 /* Aloca um i-node livre em "dev" e retorna um ponteiro para ele. */ 
23006 


23007 register struct inode “rip; 

23008 register struct super block *sp; 

23009 int major, minor, inumb; 

23010 bit tb; 

23011 

23012 sp = get super(dev); /* obtém ponteiro para super block */ 
23013 if (sp->s rd only) { /* não pode alocar i-node em um dispositivo somente para leitura. */ 
23014 err code = EROFS; 

23015 return(NIL INODE); 

23016 } 

23017 


23018 /* Adquire um i-node do mapa de bits. */ 
23019 b = alloc_bit(sp, IMAP, sp->s_isearch); 
23020 if (b == NO_BIT) { 


23021 err code = ENFILE; 
23022 major = (int) (sp->s dev >> MAJOR) & BYTE; 
23023 minor = (int) (sp->s dev >> MINOR) & BYTE; 


23024 printf("Out of i-nodes on %sdevice %d/%d\n", 
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23025 
23026 
23027 
23028 
23029 
23030 
23031 
23032 
23033 
23034 
23035 
23036 
23037 
23038 
23039 
23040 
23041 
23042 
23043 
23044 
23045 
23046 
23047 
23048 
23049 
23050 
23051 
23052 
23053 
23054 
23055 


23057 
23058 
23059 
23060 
23061 
23062 
23063 
23064 
23065 
23066 
23067 
23068 
23069 
23070 
23071 
23072 
23073 
23074 


23076 
23077 
23078 
23079 
23080 
23081 
23082 
23083 
23084 


sp->s dev == root dev ? "root " : "", major, minor); 
return(NIL INODE); 
} 
sp->s_isearch = b; /* na próxima vez, começa aqui */ 
inumb = (Cint) b; /* cuidado para não passar unshort como param */ 


/* Tenta adquirir uma entrada na tabela de i-nodes. */ 
if (Crip = get_inode(NO_DEV, inumb)) == NIL_INODE) { /* Nenhuma entrada na tabela 
de i-nodes está disponível. Libera o i-node recentemente alocado. */ 
free bit(sp, IMAP, b); 


} else { 
/* Uma entrada de i-node está disponível. Coloca i-node recentemente alocado. */ 
rip->i mode = bits; /* configura os bits RWX */ 
rip->i nlinks = 0; /* inicial sem vínculos */ 
rip->i uid = fp->fp effuid; /* o uid do arquivo é o do proprietário */ 
rip->i gid = fp->fp effgid; /* o mesmo para o id de grupo */ 
rip->i dev = dev; /* marca em qual dispositivo ele está */ 


rip->i ndzones = sp->s ndzones; /* número de zonas diretas */ 
rip->i nindirs = sp->s nindirs; /* número de zonas indiretas por blc*/ 
rip->i sp = sp; /* ponteiro para superbloco */ 


/* Os campos não limpos já são limpos em wipe inode(). Eles foram 
* colocados lá porque truncate() precisa limpar os mesmos campos, se 

o arquivo for aberto enquanto estiver sendo truncado. Economiza espaço 
* não repetir o código duas vezes. 


žy 
wipe_inode(rip); 
} 
return(rip); 

} 

/* === ¥ 
hi wipe inode * 
ER e e e O e a RS 

PUBLIC void wipe inode(rip) 

register struct inode “rip; /* o i-node a ser apagado */ 

{ 


/* Apaga alguns campos no i-node. Esta função é chamada a partir de alloc inode(), 
* quando um novo i-node precisa ser alocado, e a partir de truncate(), quando um i-node 
* já existente precisa ser truncado. 


*/ 
register int i; 


rip->i_size = 0; 

rip->i_update = ATIME | CTIME | MTIME; /* atualiza todos os tempos posteriormente */ 
rip->i dirt = DIRTY; 

for Ci = 0; i < V2 NR TZONES; i++) rip->i zone[i] = NO ZONE; 


} 

JŽ ======== * 
* free inode * 
dD=D==D==D>=2>=>>>>=>>>>>=>>=>=>>>>>=>>=>>>>>>=>>>>>>>>>=>>=>>>=>>>>=>=>>=>>=>=>>=>=>>===>==== * / 

PUBLIC void free inode(dev, inumb) 

dev t dev; /* em que dispositivo está o i-node */ 

ino t inumb; /* número do i-node a ser liberado */ 

{ 


/* Retorna um i-node para o pool de i-nodes não alocados. */ 
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23085 
23086 
23087 
23088 
23089 
23090 
23091 
23092 
23093 
23094 


23096 
23097 
23098 
23099 
23100 
23101 
23102 
23103 
23104 
23105 
23106 
23107 
23108 
23109 
23110 
23111 
23112 
23113 
23114 
23115 
23116 
23117 
23118 
23119 
23120 


23122 
23123 
23124 
23125 
23126 
23127 
23128 
23129 
23130 
23131 
23132 
23133 
23134 
23135 
23136 
23137 
23138 
23139 
23140 
23141 
23142 
23143 
23144 


register struct super block *sp; 
bit tb; 


/* Localiza o super block apropriado. */ 

sp = get super(dev); 

if Cinumb <= O || inumb > sp->s ninodes) return; 
b = inumb; 

free bit(sp, IMAP, b); 

if (b < sp->s isearch) sp->s isearch = b; 


PUBLIC void update times(rip) 
register struct inode *rip; /* ponteiro para o i-node a ser Tlido/escrito */ 
{ 
/* Várias chamadas de sistema são exigidas pelo padrão para atualizar atime, ctime ou 
* mtime. Como atualizar um tempo exige o envio de uma msg. para a tarefa de relógio --uma 
* atividade dispendiosa--, os tempos são marcados para atualização por meio da ativação 
de bits em i update. Quando é executada uma função stat, fstat ou sync, ou quando um 
i-node é liberado, update times() pode ser chamada para realmente preencher os tempos. 


*/ 


time t cur time; 
struct super block *sp; 


sp = rip->i sp; /* obtém ponteiro para superbloco. */ 
if (sp->s rd only) return; /* nenhuma atualização para FS somente para leitura */ 


cur time = clock time(Q); 

if (Crip->i update & ATIME) rip->i atime = cur time; 

if (rip->i update & CTIME) rip->i ctime = cur time; 

if (Crip->i update & MTIME) rip->i mtime = cur time; 

rip->i update = 0; /* agora, todos estão atualizados */ 


PUBLIC void rw inode(rip, rw flag) 

register struct inode “rip; /* ponteiro para i-node a ser lido/escrito */ 
int rw flag; /* READING ou WRITING */ 

{ 


/* Uma entrada na tabela de i-nodes precisa ser copiada no (ou do) disco. */ 


register struct buf *bp; 
register struct super block *sp; 
di inode *dip; 

d2 inode *dip2; 

block t b, offset; 


/* Obtém o bloco onde reside o i-node. */ 

sp = get super(rip->i dev); /* obtém ponteiro para superbloco */ 

rip->i sp = sp; /* o i-node deve conter ponteiro de superbloco */ 
offset = sp->s imap blocks + sp->s zmap blocks + 2; 

b = (block t) Crip->i num - 1)/sp->s inodes per block + offset; 

bp = get blockCrip->i dev, b, NORMAL); 

dip = bp->b vi ino + (Crip->i num - 1) % V1 INODES PER BLOCK; 

dip2 = bp->b v2 ino + Crip->i num - 1) % 
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PRIVATE void old -icopy(rip, dip, direction; 
register struct inode * 


V2_INODES_PER_BLOCK(sp->s_block_size); 


/* Realiza a leitura ou escrita. */ 

if (rw flag == WRITING) { 
if (Crip->i update) update times(rip); /* os tempos precisam de atualização */ 
if (sp->s rd only == FALSE) bp->b dirt = DIRTY; 

} 


/* Copia o i-node do bloco de disco na tabela no núcleo ou vice-versa. 
* Se o quarto parâmetro abaixo for FALSE, os bytes serão trocados. 
*/ 
if (sp->s version == V1) 
old icopyCrip, dip, rw flag, sp->s native); 
else 
new icopy(rip, dip2, rw flag, sp->s native); 
put bTockCbp, INODE BLOCK); 
rip->i dirt = CLEAN; 


norm) 


“rip; * ponteiro para a estrutura de i-node no núcleo */ 


register dl inode *dip; 
int direction; 
int norm; 


{ 


a 


* TRUE = não troca bytes; FALSE = 


* ponteiro para a estrutura de i-node d1 inode */ 
* READING (do disco) ou WRITING (no disco) */ 
troca */ 


/* O disco V1.x IBM, o disco V1.x 68000 e o disco V2 (o mesmo para IBM e 


* 68000), todos têm layouts de nó-I diferentes. Quando um i-node é lido ou escrito, 
* esta rotina trata das conversões para que as informações na tabela de i-nodes 
sejam independentes da estrutura do disco de onde veio o i-node. 

* A rotina old icopy copia nos (e dos) discos V1. 


int i; 


if (direction == READING) { 


/* Copia i-node V1.x na tabela no núcleo, trocando bytes se for necessário. */ 


rip->i mode = conv2(norm, (int) dip->d1 mode); 

rip->i uid = conv2(norm, (int) dip->dl uid ); 

rip->i size = conv4(norm, dip->dl size); 

rip->i mtime = conv4(norm, dip->dl mtime); 

rip->i atime = rip->i mtime; 

rip->i ctime = rip->i mtime; 

rip->i nlinks = dip->dl nlinks; /* 1 car */ 
rip->i gid = dip->dl gid; /* 1 car */ 


rip->i ndzones = V1 NR DZONES; 
rip->i nindirs = VI INDIRECTS; 


for Ci = 0; i < VI NR TZONES; i++) 
rip->i zone[i] = conv2(norm, (int) dip->d1 zone[il); 
} else { 
/* Copiando i-node V1.x no disco a partir da tabela no núcleo. */ 
dip->d1_mode = conv2(norm, (int) rip->i_mode); 
dip->di uid = conv2(norm, (int) rip->i uid ); 
dip->dl size = conv4(norm, rip->i size); 
dip->dl mtime = conv4(norm, rip->i mtime); 


dip->di nlinks = rip->i nlinks; /* 1 car */ 
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23205 dip->d1 gid = rip->i gid; /* 1 car */ 

23206 for (Ci = 0; i < V1 NR TZONES; i++) 

23207 dip->d1 zone[i] = conv2(norm, (int) rip->i zone[il); 

23208 } 

23209 } 

23211. J7- 
23212 i new_icopy * 
23213 a a a ES ===s==* / 
23214 PRIVATE void new_icopy(rip, dip, direction, norm) 

23215 register struct inode *rip; /* ponteiro para a estrutura de i-node no núcleo */ 
23216 register d2_inode *dip; /* ponteiro para a estrutura d2_inode */ 

23217 int direction; /* READING (do disco) ou WRITING (no disco) */ 
23218 int norm; /* TRUE = não troca bytes; FALSE = troca */ 
23219 

23220 { 

23221 /* O mesmo que old icopy, mas para/de layout de disco V2. */ 

23222 

23223 Tnt is 

23224 

23225 if (direction == READING) { 

23226 /* Copia i-node V2.x na tabela no núcleo, trocando bytes se for necessário. */ 
23227 rip->i mode = conv2(norm, dip->d2 mode); 

23228 rip->i uid = conv2(norm, dip->d2 uid); 

23229 rip->i nlinks = conv2(norm,dip->d2 nlinks); 

23230 rip->i gid = conv2(norm,dip->d2 gid); 

23231 rip->i size = conv4(norm, dip->d2 size); 

23232 rip->i atime = conv4(norm, dip->d2 atime); 

23233 rip->i ctime = conv4(norm, dip->d2 ctime); 

23234 rip->i mtime = conv4(norm, dip->d2 mtime); 

23235 rip->i ndzones = V2 NR DZONES; 

23236 rip->i nindirs = V2 INDIRECTSCrip->i sp->s block size); 

23237 for (Ci = 0; i < V2 NR TZONES; i++) 

23238 rip->i zone[i] = conv4(norm, (long) dip->d2 zone[il); 

23239 } else { 

23240 /* Copiando i-node V2.x no disco a partir da tabela no núcleo. */ 
23241 dip->d2 mode = conv2(norm, rip->i mode); 

23242 dip->d2 uid = conv2(norm,rip->i uid); 

23243 dip->d2 nlinks = conv2(norm,rip->i nlinks); 

23244 dip->d2 gid = conv2(norm,rip->i gid); 

23245 dip->d2 size = conv4(norm,rip->i size); 

23246 dip->d2 atime = conv4(norm,rip->i atime); 

23247 dip->d2 ctime = conv4(norm,rip->i ctime); 

23248 dip->d2 mtime = conv4(norm,rip->i mtime); 

23249 for (Ci = 0; i < V2 NR TZONES; i++) 

23250 dip->d2 zone[i] = conv4(norm, (long) rip->i zone[il); 

23251 } 

23252 } 

23254 0 [/f======DDDD=DD=D=DD=D=DDD=DDD=DDD=D=DDD=D>D=D>D=D=2>==2D==D>>D==>==>=>==>===>>===>============== * 
23255 * dup inode fe 
23256 FESSESDESDS= SS === SESSDSSSDSSSS DOSES DSSSDDSDSSS === S SSD =Ss Ss ===== === / 
23257 PUBLIC void dup inode(ip) 

23258 struct inode *ip; /* O i-node a ser duplicado. */ 

23259 { 

23260 /* Esta rotina é uma forma simplificada de get inode() para o caso onde 

23261 * o ponteiro de i-node já é conhecido. 

23262 žy 

23263 


23264 ip->i_count++; 
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23265 


} 


APAE HHH HH H+H HH HHHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH HH+H+HH+HH+H+HH+H+H+H+H+H+ 


servers/fs/super.c 


HEHEHEHEHE HH HHHH HHHH H+H HH HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH HHHH HHHH 


23300 
23301 
23302 
23303 
23304 
23305 
23306 
23307 
23308 
23309 
23310 
23311 
23312 
23313 
23314 
23315 
23316 
23317 
23318 
23319 
23320 
23321 
23322 
23323 
23324 
23325 
23326 
23327 
23328 
23329 
23330 
23331 
23332 
23333 
23334 
23335 
23336 
23337 
23338 
23339 
23340 
23341 
23342 
23343 
23344 
23345 
23346 
23347 
23348 
23349 


/* Este arquivo gerencia a tabela de superblocos e as estruturas de dados relacionadas, 
* a saber, os mapas de bits que monitoram quais zonas e quais i-nodes estão 

alocados e quais estão livres. Quando um novo i-node ou uma nova zona é necessária, o 
mapa de bits apropriado é pesquisado em busca de uma entrada livre. 


* 


* Os pontos de entrada para este arquivo são 


* alloc bit: alguém quer alocar uma zona ou um i-node; encontra um(a) 

* free bit: indica que uma zona ou um i-node está disponível para alocação 
* get super: pesquisa a tabela de 'superblocos” em busca de um dispositivo 
* — mounted: informa se o i-node de arquivo está no FS montado (ou em ROOT) 
* read super: 1ê um superbloco 

*/ 


ginclude "fs.h" 
#include <string.h> 
#include <minix/com.h> 
#include "buf.h" 
#include "inode.h" 
#include "super.h" 
#include "const.h" 


/* === ¥ 
# alloc_bit * 
¥ === * / 
PUBLIC bit_t alloc_bit(sp, map, origin) 
struct super_block *sp; /* o sistema de arquivos de onde vai alocar */ 
int map; /* IMAP (mapa de i-nodes) ou ZMAP (mapa de zonas) */ 
bit t origin; /* número do bit para iniciar a pesquisa */ 
{ 
/* Aloca um bit de um mapa de bits e retorna seu número de bit. */ 
block_t start_block; /* primeiro bloco de bit */ 
bit_t map_bits; /* quantos bits existem no mapa de bits? */ 
unsigned bit_blocks; /* quantos blocos existem no mapa de bits? */ 


unsigned block, word, bcount; 
struct buf *bp; 

bitchunk_t *wptr, *wlim, k; 
bitt i; b; 


if (sp->s rd only) 
panic(. FILE ,"can't allocate bit on read-only filesys.", NO NUM); 


if (map == IMAP) 1 
start block = START BLOCK; 
map bits = sp->s ninodes + 1; 
bit blocks = sp->s imap blocks; 

} else { 
start_block = START_BLOCK + sp->s_imap_blocks; 
map_bits = sp->s_zones - (sp->s_firstdatazone - 1); 
bit_blocks = sp->s_zmap_blocks; 
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23350 } 

23351 

23352 /* Descobre onde vai iniciar a pesquisa de bit (depende de "origin'). */ 
23353 if (origin >= map bits) origin = 0; /* para ser robusto */ 

23354 

23355 /* Localiza o lugar de início. */ 


23356 block = origin / FS BITS PER BLOCK(sp->s block size); 

23357 word = (origin % FS BITS PER BLOCK(sp->s block size)) / FS BITCHUNK BITS; 
23358 

23359 /* Itera por todos os blocos mais um, pois começamos no meio. */ 

23360 bcount = bit blocks + 1; 

23361 do { 


23362 bp = get block(sp->s dev, start block + block, NORMAL); 

23363 wlim = &bp->b bitmap[FS BITMAP CHUNKS(sp->s block size)]; 

23364 

23365 /* Itera por todas as palavras no bloco. */ 

23366 for (wptr = &bp->b bitmap[word]; wptr < wlim; wptr++) 1 

23367 

23368 /* Essa palavra contém um bit livre? */ 

23369 if Cwptr == (bitchunk t) “0) continue; 

23370 

23371 /* Localiza e aloca o bit livre. */ 

23372 k = conv2(sp->s native, (int) *wptr); 

23373 for (1 = 0; (k & (1 << i)) != 0; ++i) {} 

23374 

23375 /* Número de bit do início do mapa de bits. */ 

23376 b = ((bit_t) block * FS_BITS_PER_BLOCK(sp->s_block_size)) 
23377 + (wptr - &bp->b_bitmap[0]) * FS_BITCHUNK_BITS 

23378 +i; 

23379 

23380 /* Não aloca bits além do fim do mapa. */ 

23381 if (b >= map_bits) break; 

23382 

23383 /* Aloca e retorna número de bit. */ 

23384 k |=1 << 1; 

23385 *wptr = conv2(sp->s native, (int) k); 

23386 bp->b dirt = DIRTY; 

23387 put block(Cbp, MAP BLOCK) ; 

23388 return(b); 

23389 3 

23390 put bTock(bp, MAP BLOCK); 

23391 if (++block >= bit blocks) block = 0; /* último bloco, retorna automaticamente */ 
23392 word = O; 

23393 } while (--bcount > 0); 

23394 return(NO BIT); /* nenhum bit pode ser alocado */ 

23395 + 

23397 /f=========================================================================== * 
23398 E free bit * 
23399 e o Doo SU SER SR RR E a mm soe? À 
23400 PUBLIC void free bit(sp, map, bit returned) 

23401 struct super block *sp; /* o sistema de arquivos no qual operar */ 
23402 int map; /* IMAP (mapa de i-nodes) ou ZMAP (mapa de zonas) */ 
23403 bit t bit returned; /* número de bit a inserir no mapa */ 

23404 | 


23405 /* Retorna uma zona ou um i-node desativando seu bit no mapa de bits. */ 
23406 

23407 unsigned block, word, bit; 

23408 struct buf *bp; 

23409 bitchunk t k, mask; 
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23410 
23411 
23412 
23413 
23414 
23415 
23416 
23417 
23418 
23419 
23420 
23421 
23422 
23423 
23424 
23425 
23426 
23427 
23428 
23429 
23430 
23431 
23432 
23433 
23434 
23435 
23436 
23437 
23438 
23439 
23440 


23442 
23443 
23444 
23445 
23446 
23447 
23448 
23449 
23450 
23451 
23452 
23453 
23454 
23455 
23456 
23457 
23458 
23459 
23460 
23461 
23462 


23464 
23465 
23466 
23467 
23468 
23469 


block t start block; 


if (sp->s rd only) 
panic(. FILE ,'"can't free bit on read-only filesys.", NO NUM); 


if (map == IMAP) 1 
start block = START BLOCK; 
} else { 
start_block = START_BLOCK + sp->s_imap_blocks; 
} 
block = bit returned / FS BITS PER BLOCK(sp->s block size); 
word = (bit returned % FS BITS PER BLOCK(sp->s block size)) 
/ FS BITCHUNK BITS; 


bit = bit returned % FS BITCHUNK BITS; 
mask = 1 << bit; 


bp = get block(sp->s dev, start block + block, NORMAL); 


k = conv2(sp->s native, (int) bp->b bitmap[word]); 
if (!(k & mask)) { 
panicC. FILE ,map == IMAP ? "tried to free unused inode" : 
“tried to free unused block", NO NUM); 
} 


k &= “mask; 
bp->b bitmap[word] = conv2(sp->s native, (int) k); 
bp->b dirt = DIRTY; 


put bTockCbp, MAP BLOCK); 


} 
/* === ¥ 

id get super j 
AEAEE EEA EEN EE / 
PUBLIC struct super_block *get_super (dev) 
dev_t dev; /* número de dispositivo cujo super_block é buscado */ 


{ 


/* Pesquisa a tabela de superblocos em busca desse dispositivo. Supõe-se que esteja lá. */ 


register struct super_block *sp; 


if (dev == NO_DEV) 
panic(_FILE_,"request for super block of NO DEV", NO NUM); 


for (sp = &super block[0]; sp < &super block[NR SUPERS]; sp++) 
if (sp->s dev == dev) return(sp); 


/* A pesquisa falhou. Algo deu errado. */ 


panic(. FILE ,"can't find superblock for device (in decimal)", (int) dev); 
return(NIL SUPER); /* para manter o compilador e lint em silêncio */ 
} 
/* === ¥ 
* get block size * 
EDDS====D=D>=>>=>>=>>=>>=>=>=>=>>=>>>>>>>=>=>=>>>>>>>=>>=>>=>>>>=>>>>>>>=>>=>=>>>=>>=>>=>===> * / 
PUBLIC int get block size(dev t dev) 
{ 


/* Pesquisa a tabela de superblocos em busca desse dispositivo. */ 
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23470 

23471 register struct super block *sp; 

23472 

23473 if (dev == NO DEV) 

23474 panic(. FILE ,"request for block size of NO DEV", NO NUM); 
23475 

23476 for (sp = &super block[0]; sp < &super block[NR SUPERS]; sp++) { 
23477 if (sp->s dev == dev) 1 

23478 return(sp->s block size); 

23479 } 

23480 } 

23481 

23482 /* nenhum sistema de arquivos montado? então, usa este tamanho de bloco. */ 
23483 return MIN_BLOCK_SIZE; 

23484 } 


23486 
23487 
23488 
23489 PUBLIC int mounted(rip) 

23490 register struct inode *rip; /* ponteiro para i-node */ 

23491 { 

23492 /* Informa se o i-node dado está em um sistema de arquivos montado (ou em ROOT). */ 
23493 


23494 register struct super_block *sp; 

23495 register dev_t dev; 

23496 

23497 dev = (dev_t) rip->i_zone[0]; 

23498 if (dev == root_dev) return(TRUE); /* o i-node está no sistema de arquivos raiz */ 
23499 

23500 for (sp = &super_block[0]; sp < &super_block[NR_SUPERS]; sp++) 

23501 if (sp->s dev == dev) return(TRUE); 

23502 

23503 return(FALSE); 

23504 + 

23506 — /f==================================>======================================== * 
23507 * read super * 
23508 FESESDESDS==S=55=5050 =D SDESCS=SDD=SDSSSSESDSS=DS== SSD SSES === =2=* / 


23509 PUBLIC int read super(sp) 

23510 register struct super block *sp; /* ponteiro para um superbloco */ 
23511 -{ 

23512 /* Lê um superbloco. */ 

23513 dev t dev; 

23514 int magic; 


23515 int version, native, r; 

23516 static char sbbuf [MIN BLOCK SIZE]; 

23517 

23518 dev = sp->s dev; /* salva o dispositivo (será sobrescrito pela cópia) */ 
23519 if (dev == NO DEV) 

23520 panic(. FILE ,"request for super block of NO DEV", NO NUM); 

23521 r = dev io(DEV READ, dev, FS PROC NR, 

23522 sbbuf, SUPER BLOCK BYTES, MIN BLOCK SIZE, 0); 

23523 if Cr != MIN BLOCK SIZE) 1 

23524 return EINVAL; 

23525 } 

23526 memcpy(sp, sbbuf, sizeof(*sp)); 

23527 sp->s_dev = NO_DEV; /* restaura posteriormente */ 

23528 magic = sp->s_magic; /* determina o tipo do sistema de arquivos */ 


23529 
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23530 
23531 
23532 
23533 
23534 
23535 
23536 
23537 
23538 
23539 
23540 
23541 
23542 
23543 
23544 
23545 
23546 
23547 
23548 
23549 
23550 
23551 
23552 
23553 
23554 
23555 
23556 
23557 
23558 
23559 
23560 
23561 
23562 
23563 
23564 
23565 
23566 
23567 
23568 
23569 
23570 
23571 
23572 
23573 
23574 
23575 
23576 
23577 
23578 
23579 
23580 
23581 
23582 
23583 
23584 
23585 
23586 
23587 
23588 
23589 


/* Obtém a versão e o tipo do sistema de arquivos. */ 
if (magic == SUPER MAGIC || magic == conv2 (BYTE SWAP, SUPER MAGIC)) 1 
version = V1; 
native = (magic == SUPER MAGIC); 
} else if (magic == SUPER V2 || magic == conv2 (BYTE SWAP, SUPER V2)) 1 
version = V2; 
native = (magic == SUPER V2); 
} else if (magic == SUPER V3) { 
version = V3; 
native = 1; 
} else { 
return(EINVAL) ; 
} 


/* Se o superbloco tem a ordem de byte errada, troca os campos; o número 
* mágico não precisa de conversão. */ 


sp->s_ninodes = conv4(native, sp->s_ninodes); 
sp->s_nzones = conv2 (native, (int) sp->s_nzones); 
sp->s_imap_blocks = conv2 (native, (int) sp->s_imap_blocks); 
sp->s_zmap_blocks = conv2 (native, (int) sp->s_zmap_blocks); 


sp->s firstdatazone = conv2(native, (int) sp->s_firstdatazone); 
sp->s log zone size = conv2(native, (int) sp->s log zone size); 
sp->s max size = conv4C(native, sp->s max size); 

sp->s zones = conv4C(native, sp->s zones); 


/* No V1, o tamanho do dispositivo era mantido em um valor short, s nzones, 
* os dispositivos a zonas de 32K. Para o V2, foi decidido manter o tamanho 
* valor long. Entretanto, apenas alterar s nzones para long não funcionari 
* então a posição de s magic no superbloco não seria a mesma 
* nos sistemas de arquivos V1 e V2, e não haveria meios de identificar se 
* um sistema de arquivos recentemente montado era V1 ou V2. A solução foi 
* uma nova variável, s zones, e copia o tamanho lá. 

* 
* Calcula alguns outros números que dependem da versão aqui também, para 
* ocultar algumas das diferenças. 
*/ 
if (version == V1) { 
sp->s_block_size = STATIC_BLOCK_SIZE; 


sp->s_zones = sp->s_nzones; /* somente o V1 precisa dessa cópia * 


sp->s inodes per block = V1 INODES PER BLOCK; 
sp->s ndzones = V1 NR DZONES; 
sp->s nindirs = V1 INDIRECTS; 
} else { 
if (version == V2) 
sp->s_block_size = STATIC_BLOCK_SIZE; 
if (sp->s_block_size < MIN BLOCK SIZE) 
return EINVAL; 
sp->s inodes per block = V2 INODES PER BLOCK(sp->s block size); 
sp->s ndzones = V2 NR DZONES; 
sp->s nindirs = V2 INDIRECTS(sp->s block size); 
} 


if (sp->s block size < MIN BLOCK SIZE) { 
return EINVAL; 
} 
if (sp->s block size > MAX BLOCK SIZE) { 
printfC"Filesystem block size is %d kB; maximum filesystemn” 
"block size is %d kB. This limit can be increased by recompiling.An”, 
sp->s block size/1024, MAX BLOCK SIZE/1024); 
return EINVAL; 


que limitava 
como um 
a, pois 


introduzir 
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23590 

23591 if (Csp->s block size % 512) != 0) { 

23592 return EINVAL; 

23593 } 

23594 if (SUPER SIZE > sp->s block size) { 

23595 return EINVAL; 

23596 } 

23597 if ((sp->s block size % V2_INODE_SIZE) != 0 || 

23598 (sp->s block size % VI INODE SIZE) != 0) 1 

23599 return EINVAL; 

23600 

23601 

23602 sp->s isearch = 0; /* as pesquisas de i-node começam inicialmente em O */ 
23603 sp->s zsearch = 0; /* as pesquisas de zona começam inicialmente em O */ 
23604 sp->s version = version; 

23605 sp->s native = native; 

23606 

23607 /* Faz algumas verificações básicas para ver se o superbloco parece razoável. */ 
23608 if (sp->s imap blocks < 1 || sp->s zmap blocks < 1 

23609 || sp->s ninodes < 1 || sp->s zones < 1 

23610 || Cunsigned) sp->s log zone size > 4) { 

23611 printf(C"not enough imap or zone map blocks, An"); 

23612 printf(C"or not enough inodes, or not enough zones, " 

23613 "or zone size too large\n"); 

23614 return(EINVAL); 

23615 } 

23616 sp->s_dev = dev; /* restaura o número do dispositivo */ 

23617 return(0K); 

23618 } 


DO one Do DO o O O HHHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH H+ O O DO OO OD O O 
servers/fs/filedes.c 
DO ssa oo O O O SD H HHH HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHHH O O DO OO OO O O 


23700 /* Este arquivo contém as funções que manipulam descritores de arquivo. 
23701 $ 


23702 * Os pontos de entrada para este arquivo são 

23703 * get fd: procura descritor de arquivo livre e entradas de filp livres 

23704 * get filp: pesquisa a entrada de filp em busca de determinado descritor de arquivo 
23705 * find filp: encontra uma entrada de filp que aponta para determinado i-node 

23706 */ 

23707 


23708 include "fs.h" 
23709 include "file.h" 
23710 #include "fproc.h" 
23711 &include "inode.h" 


23712 

23713 

23714 * get fd * 
23715 foD=D======================================================================= * / 


23716 PUBLIC int get fd(int start, mode t bits, int *k, struct filp **fpt) 
23717 { 
23718 /* Procura um descritor de arquivo livre e uma entrada de filp livre. Preenche a palavra 


23719 * de modo nesta última, mas não reivindica uma ainda, pois open) ou creat() 
23720 * ainda podem falhar. 

23721 */ 

23722 

23723 register struct filp *f; 


23724 register int i; 


APÊNDICE B e O Cóbico-FoNTE DO MINIX 899 


23725 
23726 
23727 
23728 
23729 
23730 
23731 
23732 
23733 
23734 
23735 
23736 
23737 
23738 
23739 
23740 
23741 
23742 
23743 
23744 
23745 
23746 
23747 
23748 
23749 
23750 
23751 
23752 
23753 
23754 
23755 
23756 


23758 
23759 
23760 
23761 
23762 
23763 
23764 
23765 
23766 
23767 
23768 
23769 


23771 
23772 
23773 
23774 
23775 
23776 
23777 
23778 
23779 
23780 
23781 
23782 
23783 
23784 


žk = -1; /* Flag indicativo de descritor não encontrado */ 


/* Pesquisa a tabela fproc fp filp em busca de um descritor de arquivo livre. */ 
for Ci = start; i < OPEN MAX; i++) { 
if Cfp->fp filplil == NIL FILP) { 
/* Um descritor de arquivo foi localizado. */ 
sk- ii 
break; 


} 


/* Verifica se um descritor de arquivo foi encontrado. */ 
if (*k < 0) return(EMFILE); /* é por isso que inicializamos k como -1 */ 


/* Agora que um descritor de arquivo foi encontrado, procura uma entrada de filp livre. */ 
for (f = &filp[0]; f < &filp[NR_FILPS]; f++) { 
if (f->filp_count == 0) { 
f->filp_mode = bits; 
f->filp_pos = OL; 
f->filp selectors = 0; 
f->filp select ops = 0; 
f->filp pipe select ops = 0; 
f->filp flags = 0; 
#fpt= f; 
return(0K); 


} 


/* Se o controle passar por aqui, a tabela filp deve estar cheia. Relata isso. */ 
return(ENFILE); 


} 

SN E E EE E 
K get_filp j 
Teee) 

PUBLIC struct filp *get_filp(fild) 

int fild; /* descritor de arquivo */ 

{ 


/* Testa se "fild' se refere a um desc de arquivo válido. Se sim, retorna seu ptr filp. */ 


err_code = EBADF; 
if Cfild< O || fild >= OPEN MAX ) return(NIL_FILP); 
return(fp->fp filplfildl); /* may also be NIL FILP */ 


PUBLIC struct filp *find filp(register struct inode *rip, mode t bits) 

{ 

/* Localiza uma entrada de filp que se refere ao i-node "rip" da maneira descrita pelo 
* bit de modo "bits". Usado para determinar se alguém ainda está interessado em uma das 
* extremidades de um pipe. Usado também ao abrir uma estrutura FIFO para encontrar 
* parceiros para compartilhar um campo de filp (para compartilhar a posição do arquivo). 
* Assim como "get fd”, executa sua tarefa por meio de pesquisa linear na tabela filp. 


*/ 


register struct filp *f; 
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23785 for (f = &filp[0]; f < &filpINR FILPS]; f++) { 


23786 if (f->filp count != 0 && f->filp ino == rip && (f->filp mode & bits)){ 
23787 return(f); 

23788 } 

23789 } 

23790 

23791 /* Se o controle passar por aqui, a tabela filp não estava lá. Relata isso. */ 
23792 return(NIL FILP); 

23793 + 


HHHHHEHHHHHHH EH OD RO DO HHHH HHHH HHHH HHH H+H HH HHHH HHHH HHHH H+ O O O DO OO OO O O 
servers/fs/lock.c 
DO spa oo o RS a O DO HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH HHH O DD O O OD O 


23800 /* Este arquivo manipula a trava consultiva de arquivo, conforme exigido pelo POSIX. 
23801 ii 


23802 * Os pontos de entrada para este arquivo são 

23803 *  Tock op: executa operações de trava para a chamada de sistema FCNTL 
23804 * Tock revive: reanima processos quando uma trava é liberada 

23805 74 

23806 


23807 include "fs.h" 

23808 &include <minix/com.h> 
23809 #include <fcntl.h> 
23810 #include <unistd.h> 
23811 #include "file.h" 
23812 #include "fproc.h" 
23813 #include "inode.h" 
23814 #include "lock.h" 
23815 #include "param.h" 


23816 

23817 /*==================== * 
23818 * lock op * 
23819 E EDD=D==D=D>D>=>>=>>=>>>>>==>=>>=>>>>>>=>=>>=>>=>>>>>=>=>>=>>=>>>>>>=>>=>>=>>=>>=>>>>=>=>=>=>===="* / 


23820 PUBLIC int Tock op(f, reg) 
23821 struct filp *f; 


23822 int reg; /* F SETLK ou F SETLKW */ 
23823 { 

23824 /* Executa o travamento consultivo exigido pelo POSIX. */ 
23825 


23826 int r, ltype, i, conflict = 0, unlocking = 0; 
23827 mode_t mo; 

23828 off_t first, last; 

23829 struct flock flock; 

23830 vir_bytes user_flock; 

23831 struct file_lock *flp, *flp2, *empty; 


23832 

23833 /* Busca a estrutura flock em espaço de usuário. */ 

23834 user flock = (vir bytes) m in.namel; 

23835 r = sys datacopy(who, (vir bytes) user flock, 

23836 FS PROC NR, (vir bytes) &flock, (phys bytes) sizeof(flock)); 
23837 if (r != OK) return(EINVAL); 

23838 

23839 /* Faz algumas verificações de erro. */ 


23840 ltype = flock.1 type; 

23841 mo = f->filp mode; 

23842 if (ltype != F UNLCK && Ttype != F RDLCK && ltype != F WRLCK) return(EINVAL); 
23843 if (req == F GETLK && ltype == F UNLCK) return(EINVAL) ; 

23844 if C (f->filp ino->i mode & I TYPE) != I REGULAR) return(EINVAL); 
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23845 
23846 
23847 
23848 
23849 
23850 
23851 
23852 
23853 
23854 
23855 
23856 
23857 
23858 
23859 
23860 
23861 
23862 
23863 
23864 
23865 
23866 
23867 
23868 
23869 
23870 
23871 
23872 
23873 
23874 
23875 
23876 
23877 
23878 
23879 
23880 
23881 
23882 
23883 
23884 
23885 
23886 
23887 
23888 
23889 
23890 
23891 
23892 
23893 
23894 
23895 
23896 
23897 
23898 
23899 
23900 
23901 
23902 
23903 
23904 


if (req != F GETLK && Ttype == F RDLCK && (mo & R BIT) == 0) return(EBADF); 
if (req != F GETLK && Ttype == F WRLCK && (mo & W BIT) == 0) return(EBADF); 


/* Calcula o primeiro e o último byte na região de trava. */ 
switch (flock.1 whence) { 
case SEEK SET: first = 0; break; 
case SEEK CUR: first = f->filp pos; break; 
case SEEK END: first = f->filp ino->i size; break; 
default: return(EINVAL) ; 


} 

/* Verifica se houve estouro. */ 

if (CClong)flock.l_start > 0) && ((first + flock.l_start) < first)) 
return(EINVAL); 

if (C(Clong)flock.1 start < 0) && ((first + flock.1 start) > first)) 
return(EINVAL); 

first = first + flock.1 start; 

last = first + flock.l Ten - 1; 

if (flock.1 Ten == 0) last = MAX FILE POS; 

if (last < first) return(EINVAL); 


/* Verifica se essa região entra em conflito com qualquer trava já existente. */ 
empty = (struct file lock *) 0; 
for (flp = &file Tock[0]; flp < & file Tock[NR LOCKS]; flp++) { 
if (flp->lock type == 0) 1 
if (empty == (struct file lock *) 0) empty = flp; 
continue; /* O significa entrada não usada */ 
} 
if (flp->lock_inode != f->filp_ino) continue; /* arquivo diferente */ 
if (last < flp->lock_first) continue; /* o novo está na frente */ 
if (first > flp->lock_last) continue; /* o novo está depois */ 
if (ltype == F RDLCK && flp->lock type == F RDLCK) continue; 
if Cltype != F UNLCK && flp->lock pid == fp->fp pid) continue; 


/* Pode haver um conflito. Processa-o. */ 
conflict = 1; 
if (req == F GETLK) break; 


/* Se estamos tentando configurar uma trava, apenas falhou. */ 
if Cltype == F RDLCK || Ttype == F WRLCK) 1 
if (req == F SETLK) { 
/* Para F SETLK, apenas relata a falha. */ 


return(EAGAIN); 
} else { 
/* Para F_SETLKW, suspende o processo. */ 
suspend(XLOCK) ; 
return (SUSPEND) ; 
} 


} 


/* Estamos liberando uma trava e encontramos algo que se sobrepõe. */ 
unlocking = 1; 
if (first <= flp->lock_first && last >= flp->lock_last) { 


flp->lock_type = 0; /* marca a entrada como não usada */ 
nr_locks--; /* o número de travas agora é 1 a menos */ 
continue; 


} 


/* Parte de uma região bloqueada foi destravada. */ 
if (first <= flp->lock_first) { 
flp->lock_first = last + 1; 
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23905 
23906 
23907 
23908 
23909 
23910 
23911 
23912 
23913 
23914 
23915 
23916 
23917 
23918 
23919 
23920 
23921 
23922 
23923 
23924 
23925 
23926 
23927 
23928 
23929 
23930 
23931 
23932 
23933 
23934 
23935 
23936 
23937 
23938 
23939 
23940 
23941 
23942 
23943 
23944 
23945 
23946 
23947 
23948 
23949 
23950 
23951 
23952 
23953 
23954 
23955 
23956 
23957 
23958 
23959 


} 


continue; 


if (last >= flp->lock_last) { 


} 


flp->lock_last = first - 1; 
continue; 


/* Má sorte. Uma trava foi dividida em duas pelo destravamento no meio. */ 
if (nr Tocks == NR LOCKS) return (ENOLCK); 


for (Ci 


= 0; i < NR LOCKS; i++) 


if (file Tock[i].lock type == 0) break; 


flp2 = &file Tock[il; 

flp2->1ock type = flp->lock type; 
flp2->1ock pid = flp->lock pid; 
flp2->1ock inode = flp->1lock inode; 
flp2->1ock first = last + 1; 
flp2->1ock last = flp->lock last; 
flp->lock last = first - 1; 

nr locks++; 


} 


if (unlocking) lock revive); 


if (req == F_GETLK) { 
if (conflict) { 


/* GETLK e conflito. Informa sobre a trava conflitante. */ 
flock.1 type = flp->lock_type; 

flock.1 whence = SEEK SET; 

flock.1 start = flp->lock first; 

flock.1 Ten = flp->lock last - flp->lock first + 1; 
flock.1 pid = flp->lock pid; 


+ else { 


} 


/* É GETLK e não há conflito. */ 
flock.1 type = F UNLCK; 


/* Copia a estrutura flock de volta no processo que fez a chamada. */ 
r = sys datacopy(FS PROC NR, (vir bytes) &flock, 


who, (vir bytes) user flock, (phys bytes) sizeof(flock)); 


return(r); 


} 


if (ltype == F UNLCK) return(OK); /* destrava uma região sem travas*/ 


/* Não há nenhum conflito. Se existir espaço, armazena a nova trava na tabela. 


if (empty == (struct file_lock *) 0) return(ENOLCK); /* tabela cheia */ 
empty->lock_type = ltype; 

empty->lock_pid = fp->fp_pid; 

empty->lock_inode = f->filp_ino; 

empty->lock_first = first; 

empty->lock_last = last; 


nr Tocks++; 
return(OK); 


*/ 
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24000 
24001 
24002 
24003 
24004 
24005 
24006 
24007 
24008 
24009 
24010 
24011 
24012 
24013 
24014 
24015 
24016 
24017 
24018 
24019 
24020 
24021 
24022 
24023 
24024 
24025 
24026 
24027 
24028 
24029 


PUBLIC void lock_revive() 
{ 


/* Encontra todos os processos que estão esperando por qualquer tipo de trava e 


reanima a todos. Aqueles que ainda estão travados continuarão travados ao serem 
* executados. Os outros terminarão. Essa estratégia é um compromisso entre 
tempo e espaço. Descobrir exatamente quais devem ser desbloqueados agora exigiria 
código extra e o único ganho seria no desempenho em 
* circunstâncias extremamente raras (a saber, se alguém realmente usou a 


* trava). 


int task; 
struct fproc *fptr; 


for (fptr = &fproc[INIT PROC NR + 1]; fptr < &fproc[NR PROCS]; fptr++){ 


task = -fptr->fp task; 


if (Cfptr->fp suspended == SUSPENDED && task == XLOCK) 1 
revive( (int) (fptr - fproc), 0); 


} 


/* Este arquivo contém o programa principal do Sistema de Arquivos. Ele consiste em 
* um laço que recebe mensagens solicitando trabalho, realiza o trabalho e envia 


respostas. 


servers/fs/main.c 


* Os pontos de entrada para esse arquivo são: 


* main: programa principal do Sistema de Arquivos 
reply: envia uma resposta para um processo, após o trabalho solicitado ter terminado 


*/ 
struct super_block; 


#include "fs.h" 

#include <fcnt1.h> 
#include <string.h> 
#include <stdio.h> 
#include <signal.h> 
#include <stdlib.h> 
#include <sys/ioc_memory .h> 
#include <sys/svrctl.h> 
#include <minix/callnr.h> 
#include <minix/com.h> 
#include <minix/keymap.h> 
#include <minix/const.h> 
#include "buf.h" 

#include "file.h" 
#include "fproc.h" 
#include "inode.h" 
#include "param.h" 
#include "super.h" 


/* proto.h precisa saber disso */ 
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24030 
24031 
24032 
24033 
24034 
24035 
24036 
24037 
24038 
24039 
24040 
24041 
24042 
24043 
24044 
24045 
24046 
24047 
24048 
24049 
24050 
24051 
24052 
24053 
24054 
24055 
24056 
24057 
24058 
24059 
24060 
24061 
24062 
24063 
24064 
24065 
24066 
24067 
24068 
24069 
24070 
24071 
24072 
24073 
24074 
24075 
24076 
24077 
24078 
24079 
24080 
24081 
24082 
24083 
24084 
24085 
24086 
24087 
24088 
24089 


FORWARD | PROTOTYPE( void fs init, (void) ) 
FORWARD _PROTOTYPE(Ç int igetenv, (char *var, int optional) ) 
FORWARD | PROTOTYPE( void get work, (void) Jj 
FORWARD | PROTOTYPE( void load ram, (void) J 
FORWARD | PROTOTYPE( void load super, (Dev t super dev) ) 


JE ça 
i main * 
E ÊÃÇÃÇãÇÃãrH TÁ 

PUBLIC int mainQO 

{ 


/* Este é o programa principal do sistema de arquivos. O laço principal consiste em 
* três atividades fundamentais: obter novo trabalho, processar o trabalho e enviar a 
* resposta. Este laço nunca termina, contanto que o sistema de arquivos esteja em execução. 
*/ 
sigset_t sigset; 
int error; 


fs initO; 


/* Este é o laço principal que recebe trabalho, o processa e envia respostas. */ 
while (TRUE) 1 
get work (); /* inicializa who e call nr */ 


fp = &fproc[who]; /* ponteiro para estrutura da tabela de proc */ 
super user = (fp->fp effuid == SU UID ? TRUE : FALSE); /* su? */ 


/* Verifica primeiro as mensagens de controle especiais. */ 
if (call nr == SYS SIG) { 
sigset = m in.NOTIFY ARG; 
if (sigismember (&sigset, SIGKSTOP)) { 
do sync); 
sys exit(0); /* nunca retorna */ 
} 
} else if (call nr == SYN ALARM) { 
/* Não é uma requisição de usuário; o sistema expirou um de nossos 
* temporizadores, correntemente em uso para select(D. Testar isso. 
*/ 
fs expire timers(m in.NOTIFY TIMESTAMP) ; 
} else if ((call nr & NOTIFY MESSAGE)) { 
/* O dispositivo nos notifica sobre um evento. */ 
dev status(ê&m in); 
+ else { 
/* Chama a função interna que realiza o trabalho. */ 
if (call nr < 0O || call nr >= NCALLS) 1 
error = ENOSYS; 
printfC"FS,warning illegal %d system call by %din",call nr,who); 
} else if (fp->fp pid == PID FREE) { 
error = ENOSYS; 
printfC"FS, bad process, who = %d, call nr = %d, slotl = %d\n", 
who, call nr, m in.slot1); 
} else { 
error = (*call_vec[call_nr]) O; 


} 


/* Copia os resultados de volta para o usuário e envia resposta. */ 
if (error != SUSPEND) { reply(who, error); } 
if (rdahed inode != NIL_INODE) { 

read_ahead(); /* faz leitura de bloco antecipada */ 
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24090 
24091 
24092 
24093 
24094 


24096 
24097 
24098 
24099 
24100 
24101 
24102 
24103 
24104 
24105 
24106 
24107 
24108 
24109 
24110 
24111 
24112 
24113 
24114 
24115 
24116 
24117 
24118 
24119 
24120 
24121 
24122 
24123 
24124 
24125 
24126 
24127 


24129 
24130 
24131 
24132 
24133 
24134 
24135 
24136 
24137 
24138 
24139 
24140 
24141 
24142 
24143 
24144 
24145 
24146 
24147 
24148 
24149 


; 
} 
} 
return(0K); /* não deve chegar aqui */ 

} 

/* === ¥ 
* get work * 
EDDS==D=DDD>=>>=>>>>>>>=>=>=>>=>>>>>>>=>>=>>=>>>>>=>=>>=>>=>>>>>>>>>=>>=>>=>>>>=>>>==>==>===> * / 

PRIVATE void get work() 

{ 


/* Normalmente, espera por nova entrada. Entretanto, se 'reviving' for 
* diferente de zero, um processo suspendo deverá ser despertado. 
*/ 


register struct fproc *rp; 


if Creviving != 0) 1 
/* Reanima um processo suspenso. */ 
for (Crp = &fproc[0]; rp < &fproc[NR PROCS]; rp++) 
if (rp->fp revived == REVIVING) { 
who = (int)Crp - fproc); 
call nr = rp->fp fd & BYTE; 
min.fd = Crp->fp fd >>8) & BYTE; 
min.buffer = rp->fp buffer; 
min.nbytes = rp->fp nbytes; 
rp->fp suspended = NOT SUSPENDED; /*não está mais suspenso */ 
rp->fp revived = NOT REVIVING; 
reviving--; 
return; 
} 
panic(. FILE ,"get work couldn't revive anyone", NO NUM); 
} 


/* Caso normal. Nenhum para reanimar. */ 

if (receive(ANY, &m_in) != OK) panic( FILE ,"fs receive error", NO NUM); 
who = m in.m source; 

call nr =m in.m type; 


} 

/* === ¥ 
i buf. pool * 
dE=D=====D>=2==>>=>>=>>=>=>>=>>=>>=>>>>>=>>>>>>=>>=>>>>=>>>>>=>=>>>>>>>=>>=>>=>=>=>>=>=>>===>==== * / 

PRIVATE void buf pool (void) 

{ 


/* Inicializa o pool de buffers. */ 
register struct buf *bp; 


bufs in use = 0; 
front = &buf[0]; 
rear = &buf[NR BUFS - 1]; 


for (bp = &buf[0]; bp < &buf[NR BUFS]; bp++) 1 
bp->b blocknr = NO BLOCK; 
bp->b dev = NO DEV; 
bp->b next = bp + 1; 
bp->b prev = bp - 1; 


} 
buf[0].b_prev = NIL_BUF; 
buf [NR_BUFS - 1].b_next = NIL_BUF; 
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24150 
24151 
24152 
24153 
24154 


24156 
24157 
24158 
24159 
24160 
24161 
24162 
24163 
24164 
24165 
24166 
24167 
24168 
24169 
24170 
24171 


24173 
24174 
24175 
24176 
24177 
24178 
24179 
24180 
24181 
24182 
24183 
24184 
24185 
24186 


24187 
24188 
24189 
24190 
24191 
24192 
24193 
24194 
24195 
24196 
24197 
24198 
24199 
24200 
24201 
24202 
24203 
24204 
24205 
24206 
24207 
24208 
24209 


for (bp = &buf[0]; bp < &buf [NR BUFS]; bp++) bp->b hash = bp->b next; 
buf hash[0] = front; 


} 
/* === ¥ 
x reply x 
¥ === * / 
PUBLIC void reply(whom, result) 
int whom; /* processo para o qual responder */ 
int result; /* resultado da chamada (normalmente, OK ou nr. do erro) */ 
{ 


/* Envia uma resposta para um processo de usuário. Isso pode falhar (se o processo tiver 
* acabado de ser eliminado por um sinal); portanto, não verifica o código de retorno. Se 
* o envio falhar, apenas o ignora. 

*/ 

int ss 

m out.reply type = result; 

s = send(whom, &m out); 

if (s != OK) printfC"FS: couldn't send reply %d: %d\n", result, s); 


} 

JŽ ======== * 
* fs init * 
a) 

PRIVATE void fs initO 

{ 


/* Inicializa variáveis globais, tabelas etc. */ 
register struct inode *rip; 
register struct fproc *rfp; 
message mess; 
Int'ss 


/* Inicializa a tabela de processos com ajuda das mensagens do gerenciador de processos. 
* Espera uma mensagem para cada processo de sistema com seu número de entrada e pid. 
* Quando mais nenhum processo vier em seguida, o número mágico de processo NONE é 
enviado. 
* Então, pára e sincroniza com o PM. 
*/ 
do { 
if (OK != (s=receive(PM_PROC_NR, &mess))) 
panic(_FILE__,"FS couldn't receive from PM", s); 
if (NONE == mess.PR_PROC_NR) break; 


rfp = &fproc[mess.PR PROC NR]; 
rfp->fp pid = mess.PR PID; 

rfp->fp realuid = (uid t) SYS UID; 
rfp->fp effuid = (uid t) SYS UID; 
rfp->fp realgid = (gid t) SYS GID; 
rfp->fp effgid = (gid t) SYS GID; 
rfp->fp umask = “0; 


} while (TRUE); 
mess.m_type = OK; 
s=send(PM PROC NR, ê&mess); 


* continua até o processo NONE */ 
* informa o PM que tivemos êxito */ 
* envia mensagem de sincronização */ 


B Ai PO 


/* Todas as entradas da tabela de processos foram configuradas. Continue com a 
* inicialização do FS. Certas relações devem valer para o FS funcionar. Alguns 
* requisitos extras de block_size são verificados no momento da leitura do superbloco. 


*/ 
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24210 
24211 
24212 
24213 
24214 
24215 
24216 
24217 
24218 
24219 
24220 
24221 
24222 
24223 
24224 
24225 
24226 
24227 
24228 
24229 
24230 
24231 
24232 
24233 
24234 
24235 
24236 


24238 
24239 
24240 
24241 
24242 
24243 
24244 
24245 
24246 
24247 
24248 
24249 
24250 
24251 
24252 
24253 
24254 
24255 


24257 
24258 
24259 
24260 
24261 
24262 
24263 
24264 
24265 
24266 
24267 
24268 
24269 


if (OPEN MAX > 127) panic(. FILE ,"OPEN MAX > 127", NO NUM); 
if (NR BUFS < 6) panic( FILE ,"NR BUFS < 6", NO NUM); 
if (V1 INODE SIZE != 32) panic( FILE ,"Vv1 inode size != 32", NO NUM); 
if (V2 INODE SIZE != 64) panic( FILE ,"v2 inode size != 64", NO NUM); 
if (OPEN MAX > 8 * sizeof(long)) 

panic(. FILE ,"Too few bits in fp cloexec”, NO NUM); 


/* As inicializações a seguir são necessárias para permitir que dev opcl tenha êxito. */ 
fp = (struct fproc *) NULL; 
who = FS PROC NR; 


buf pool); /* inicializa o pool de buffers */ 

build dmapO; /* constrói tab. de dispositivos e mapeia driver de inicialização */ 
load ram); /* inicializa o disco de RAM, carrega, se for o raiz */ 

load super(root dev);/* carrega superbloco do dispositivo-raiz */ 

init select O; /* inicializa as estruturas selectO */ 


/* O dispositivo-raiz agora pode ser acessado; configura diretórios de processo. */ 
for (rfp=&fproc[0]; rfp < &fproc[NR PROCS]; rfp++) { 
if Crfp->fp pid != PID FREE) 1 
rip = get inode(root dev, ROOT INODE); 
dup inode(rip); 
rfp->fp rootdir = rip; 
rfp->fp workdir = rip; 


} 
} 

} 

/* === ¥ 
hd igetenv * 
aE EE / 

PRIVATE int igetenv(key, optional) 

char *key; 

int optional; 

{ 


/* Pede ao núcleo uma variável de ambiente de inicialização com valor inteiro. */ 
char value[64]; 
int i; 


if (Ci = env get param(key, value, sizeof(value))) != OK) { 
if C!optional) 
printfC"FS: Warning, couldn't get monitor param: %d\n", i); 


return 0; 
} 
return(atoi (value)); 

} 

/* === ¥ 
* load ram * 
E TT Te * Vá 

PRIVATE void load ram(void) 

{ 


/* Aloca um disco de RAM com o tam. dado nos parâmetros de inicialização. Se for dada uma 
* imagem do disco de RAM, copia o dispositivo de imagem inteiro, bloco por bloco, em um 
* disco de RAM com o mesmo tam. da imagem. Se o dispositivo-raiz não estiver 
* configurado, o disco de RAM é usado como raiz em seu lugar. 
*/ 
register struct buf *bp, *bp1; 
u32 t lcount, ram size kb; 
zone t zones; 
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24270 struct super block *sp, *dsp; 

24271 block t b; 

24272 Dev t image dev; 

24273 static char sbbuf [MIN BLOCK SIZE]; 

24274 int block size image, block size ram, ramfs block size; 
24275 int s; 

24276 

24277 /* Obtém algumas variáveis de ambiente de inicialização. */ 
24278 root dev = igetenv("rootdev", 0); 

24279 image dev = igetenv("ramimagedev", 0); 

24280 ram size kb = igetenv("ramsize”, 0); 

24281 


24282 /* Abre o dispositivo-raiz. */ 
24283 if (dev open(lroot dev, FS PROC NR, R BIT|W BIT) != OK) 


24284 panic(. FILE ,"Cannot open root device",NO NUM); 

24285 

24286 /* Para inicializar um disco de ram, obtém os detalhes do dispositivo de imagem. */ 

24287 if (root dev == DEV RAM) 1 

24288 u32 t fsmax, probedev; 

24289 

24290 /* Se estamos executando a partir de CD, verifica se podemos encontrá-lo. */ 

24291 if (igetenv("cdproberoot", 1) && (probedev=cdprobe()) != NO DEV) 1 

24292 char devnum[10]; 

24293 struct sysgetenv env; 

24294 

24295 /* Se assim for, este é nosso novo dispositivo de imagem de RAM. */ 

24296 image dev = probedev; 

24297 

24298 /* Informa o PM sobre isso, para que usuários possam descobrir a seu 
respeito 

24299 * com a interface sysenv. 

24300 */ 

24301 env.key = "cdproberoot"; 

24302 env.keylen = strlen(env.key); 

24303 sprintf(devnum, "%d", (int) probedev); 

24304 env.val = devnum; 

24305 env.vallen = strlen(devnum); 

24306 svrct] (MMSETPARAM, &env); 

24307 } 

24308 

24309 /* Abre o dispositivo de imagem para raiz de RAM. */ 

24310 if (dev_open(image_dev, FS PROC NR, R BIT) != OK) 

24311 panic(. FILE ,"Cannot open RAM image device", NO NUM); 

24312 

24313 /* Obtém o tamanho da imagem do disco de RAM a partir do superbloco. */ 

24314 sp = &super block[0]; 

24315 sp->s dev = image dev; 

24316 if (read super(sp) != OK) 

24317 panic(C. FILE ,"Bad RAM disk image FS", NO NUM); 

24318 

24319 lcount = sp->s zones << sp->s log zone size; /* nº de blcs no disp-raiz */ 

24320 

24321 /* Aumenta o sistema de arquivos do disco de RAM para o tamanho dos parâmetros de 

24322 * inicialização, mas não mais do que o último bloco do mapa de bits de zona permite. 

24323 */ 

24324 if (ram size kb*1024 < Tcount*sp->s block size) 

24325 ram size kb = Tcount*sp->s block size/1024; 

24326 fsmax = (u32 t) sp->s zmap blocks * CHAR BIT * sp->s block size; 

24327 fsmax = (fsmax + (sp->s firstdatazone-1)) << sp->s log zone size; 

24328 if (ram size kb*1024 > fsmax*sp->s block size) 


24329 ram size kb = fsmax*sp->s block size/1024; 


APÊNDICE B e O CóDiGo-FONTE DO MINIX 


909 


24330 
24331 
24332 
24333 
24334 
24335 
24336 
24337 
24338 
24339 
24340 
24341 
24342 
24343 
24344 
24345 
24346 
24347 
24348 
24349 
24350 
24351 
24352 
24353 
24354 
24355 
24356 
24357 
24358 
24359 
24360 
24361 
24362 
24363 
24364 
24365 
24366 
24367 
24368 
24369 
24370 
24371 
24372 
24373 
24374 
24375 
24376 
24377 
24378 
24379 
24380 
24381 
24382 
24383 
24384 
24385 
24386 
24387 
24388 
24389 


} 


/* Informa o driver de RAM qual deve ser o tamanho do disco de RAM. */ 
m_out.m_type = DEV_IOCTL; 
m_out.PROC_NR = FS_PROC_NR; 
m_out.DEVICE = RAM_DEV; 
m_out.REQUEST = MIOCRAMSIZE; /* controle de E/S a usar */ 
m_out.POSITION = (ram_size_kb * 1024); /* requisição em bytes */ 
if ((s=sendrec(MEM PROC NR, &m out)) != OK) 
panic("FS","sendrec from MEM failed", s); 
else if (m out.REP STATUS != OK) { 
/* Informa e continua, a menos que o disco de RAM seja exigido como FS raiz. 
if (root dev != DEV RAM) 1 
report("FS","can't set RAM disk size", m out.REP STATUS); 
return; 
} else { 
panic(_FILE__,"can’t set RAM disk size", m out.REP STATUS); 


} 
} 


*/ 


/* Verifica se devemos carregar a imagem do disco de RAM; caso contrário, retorna. */ 


if (root dev != DEV RAM) 
return; 


/* Copia os blocos, um por vez, da imagem no disco de RAM. */ 
printfC"Loading RAM disk onto /dev/ram:N33[23CLoaded: O KB"); 


inode[0].i mode = I BLOCK SPECIAL; /* i-node temp para rahead() */ 
inode[0].i size = LONG MAX; 

inode[0].i dev = image dev; 

inode[0].i zone[0] = image dev; 


block size ram = get block size(DEV RAM); 
block size image = get block size(image dev); 


/* o tamanho do bloco de RAM tem de ser um múltiplo do tamanho do bloco da imagem raiz 


* para tornar a cópia mais fácil. 
if (block size image % block size ram) 1 
printfCNnram block size: %d image block size: %d\n", 
block size ram, block size image); 
panic(_ FILE , “ram disk block size must be a multiple of " 
"the image disk block size", NO NUM); 
} 


/* Carregando blocos do dispositivo de imagem. */ 
for (b = 0; b < (block_t) Tcount; b++) { 
int rb, factor; 
bp = rahead(&inode[0], b, (off_t)block_size_image * b, block size image); 
factor = block_size_image/block_size_ram; 
for(rb = 0; rb < factor; rb++) { 
bp1 = get_block(root_dev, b * factor + rb, NO READ); 
memcpy (bp1->b data, bp->b_data + rb * block size ram, 
(size t) block size ram); 
bpl->b dirt = DIRTY; 
put block(Cbp1, FULL DATA BLOCK) ; 
} 
put_block(bp, FULL DATA BLOCK); 
if (b % 11 == 0) 
printfC"\b\b\b\b\b\b\b\b\b%6ld KB”, (Clong) b * block size image)/1024L); 
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24390 
24391 
24392 
24393 
24394 
24395 
24396 
24397 
24398 
24399 
24400 
24401 
24402 
24403 
24404 
24405 
24406 
24407 
24408 
24409 
24410 
24411 
24412 
24413 
24414 
24415 
24416 
24417 
24418 
24419 
24420 
24421 


24423 
24424 
24425 
24426 
24427 
24428 
24429 
24430 
24431 
24432 
24433 
24434 
24435 
24436 
24437 
24438 
24439 
24440 
24441 
24442 
24443 
24444 
24445 
24446 
24447 
24448 
24449 


} 


/* Efetiva as alterações na RAM para que dev_io veja. */ 
do_sync(); 


printf("\rRAM disk of %u KB loaded onto /dev/ram.", (unsigned) ram size kb); 
if (root dev == DEV RAM) printf(" Using RAM disk as root FS."); 
printf" \n"); 


/* Invalida e fecha o dispositivo de imagem. */ 
invalidate(image_dev); 
dev_close(image_dev); 


/* Redimensiona o sistema de arquivos raiz do disco de RAM. */ 
if (dev_io(DEV_READ, root_dev, FS_PROC_NR, 
sbbuf, SUPER_BLOCK_BYTES, MIN_BLOCK_SIZE, 0) != MIN_BLOCK_SIZE) { 
printfC"WARNING: ramdisk read for resizing failed\n"); 
} 
dsp = (struct super_block *) sbbuf; 
if (dsp->s magic == SUPER V3) 
ramfs block size = dsp->s block size; 
else 
ramfs block size = STATIC BLOCK SIZE; 
zones = (ram size kb * 1024 / ramfs block size) >> sp->s log zone size; 


dsp->s nzones = conv2(sp->s native, (ul6 t) zones); 

dsp->s zones = conv4(sp->s native, zones); 

if (dev io(DEV WRITE, root dev, FS PROC NR, 
sbbuf, SUPER BLOCK BYTES, MIN BLOCK SIZE, 0) != MIN BLOCK SIZE) { 
printf CCWARNING: ramdisk write for resizing failed\n"); 


} 

} 

/ À e o O a e a 
load super * 
D= * / 

PRIVATE void load super(super dev) 

dev t super dev; /* lugar do qual se obtém o superbloco */ 


{ 


int bad; 
register struct super_block *sp; 
register struct inode *rip; 


/* Inicializa a tabela super_block. */ 
for (sp = &super_block[0]; sp < &super_block[NR_SUPERS]; sp++) 
sp->s_dev = NO_DEV; 


/* Lê em super_block o sistema de arquivos raiz. */ 
sp = &super_block[0]; 
sp->s_dev = super_dev; 


/* Verifica a consistência de super_block. */ 
bad = (read super(sp) != OK); 
if C!bad) { 
rip = get_inode(super_dev, ROOT_INODE); /* i-node do diretório-raiz */ 
if C Crip->i_mode & I_TYPE) != I_DIRECTORY || rip->i_nlinks < 3) bad++; 
} 
if (bad) panic( FILE__,"Invalid root file system", NO NUM); 


sp->s_imount = rip; 
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24451 
24452 
24453 
24454 


dup inode(rip); 
sp->s isup = rip; 
sp->s rd only = 0; 
return; 
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24500 
24501 
24502 
24503 
24504 
24505 
24506 
24507 
24508 
24509 
24510 
24511 
24512 
24513 
24514 
24515 
24516 
24517 
24518 
24519 
24520 
24521 
24522 
24523 
24524 
24525 
24526 
24527 
24528 
24529 
24530 
24531 
24532 
24533 
24534 
24535 
24536 
24537 
24538 
24539 
24540 
24541 
24542 
24543 
24544 
24545 


/* Este arquivo contém as funções para criar, abrir, fechar e 
* buscar arquivos. 


Os pontos de entrada para este arquivo são 

* do creat: executa a chamada de sistema CREAT 

* do open: executa a chamada de sistema OPEN 

do mknod: executa a chamada de sistema MKNOD 

* do mkdir: executa a chamada de sistema MKDIR 
* do close: executa a chamada de sistema CLOSE 
* do Iseek: executa a chamada de sistema LSEEK 

tinclude "fs.h" 

tinclude <sys/stat.h> 

tinclude <fcnt1l.h> 

tinclude <minix/calinr.h> 

tinclude <minix/com.h> 

ginclude "buf.h” 

tinclude "file.h" 

tinclude "fproc.h" 

ginclude "inode.h" 

tinclude "lock.h" 

tinclude "param.h" 

ginclude "super.h" 


gdefine offset m2 11 


PRIVATE char mode map[] = £R BIT, W BIT, R BIT|W BIT, 0}; 


FORWARD | PROTOTYPE( int common open, (int oflags, mode t omode) J; 
FORWARD | PROTOTYPE( int pipe open, (struct inode *rip,mode_t bits,int oflags)); 
FORWARD | PROTOTYPE( struct inode *new node, (char *path, mode t bits, 


zone t z0) Y3 

Jie 

i do_creat * 

X S==S2 * / 
PUBLIC int do creat() 
{ 
/* Executa a chamada de sistema creat(name, mode). */ 

int r; 

if (fetch name(m in.name, m in.name Tength, M3) != OK) return(err code); 


r = common open(O WRONLY | O CREAT | O TRUNC, (mode t) m in.mode); 
return(r); 


} 
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24547 
24548 
24549 
24550 
24551 
24552 
24553 
24554 
24555 
24556 
24557 
24558 
24559 
24560 
24561 
24562 
24563 
24564 
24565 
24566 
24567 
24568 


24570 
24571 
24572 
24573 
24574 
24575 
24576 
24577 
24578 
24579 
24580 
24581 
24582 
24583 
24584 
24585 
24586 
24587 
24588 
24589 
24590 
24591 
24592 
24593 
24594 
24595 
24596 
24597 
24598 
24599 
24600 
24601 
24602 
24603 
24604 
24605 
24606 


PUBLIC int do open) 
{ 


/* Executa a chamada de sistema open(name, flags,...). */ 


int create_mode = 0; /* é realmente mode_t, mas isso traz problemas */ 
int r; 


/* Se O CREAT estiver ativo, a abertura tem três parâmetros; caso contrário, dois. 
if (m in.mode & O CREAT) { 

create mode = m in.c mode; 

r = fetch name(m in.c name, m in.namel length, M1); 
} else { 

r = fetch_name(m_in.name, m_in.name_length, M3); 


} 


if (r != OK) return(err_code); /* o nome era impróprio */ 
r = common open(m in.mode, create mode); 
return(r); 


PRIVATE int common open(register int oflags, mode t omode) 


{ 


/* Código comum de do_creat e do open. */ 


register struct inode *rip; 
int r, b, exist = TRUE; 

dev t dev; 

mode t bits; 

off t pos; 

struct filp “fil ptr, *filp2; 


/* Faz novo mapeamento dos dois bits inferiores de oflags. */ 
bits = (mode t) mode map[oflags & O ACCMODE] ; 


/* Verifica se o descritor de arquivo e as entradas de filp estão disponíveis. */ 
if C Cr = get_fd(0, bits, &m in.fd, &fil ptr)) != OK) return(r); 


/* Se O CREATE estiver ativo, tenta fazer o arquivo. */ 
if Coflags & O CREAT) 1 
/* Cria um novo i-node chamando new node(). */ 
omode = I REGULAR | (Comode & ALL MODES & fp->fp umask); 
rip = new node(user path, omode, NO ZONE); 
r = err code; 
if (r == OK) exist = FALSE; /* acabamos de criar o arquivo */ 
else if (r != EEXIST) return(r); /* outro erro */ 
else exist = !(oflags & O EXCL); /* o arquivo existe, se o flag 
O EXCL estiver ativo, isso é um erro */ 
} else { 
/* Percorre o nome de caminho. */ 
if C Crip = eat_path(user_path)) == NIL_INODE) return(err_code); 
} 


/* Reivindica o descritor de arquivo e a entrada de filp e os preenche. */ 
fp->fp_filp[m_in.fd] = fil_ptr; 


E 
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24664 
24665 
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fil ptr->filp count = 1; 
fil ptr->filp ino = rip; 
fil ptr->filp flags = oflags; 


/* Apenas faz o código de abertura normal se não criamos o arquivo. */ 
if (exist) { 
/* Verifica as proteções. */ 
if (Cr = forbidden(rip, bits)) == OK) { 
/* A abertura de diretórios de arquivos normais e especiais é diferente. */ 
switch (rip->i_mode & I_TYPE) { 
case I_REGULAR: 
/* Trunca arquivo normal, se for O TRUNC. */ 
if Coflags & O TRUNC) 1 
if (Cr = forbiddenCrip, W BIT)D) !=0K) break; 
truncate(rip); 
wipe inode(rip); 
/* Envia o i-node da cache de i-node para a 
* cache de bloco, para que ele seja escrito na próxima 
* descarga da cache. 
*/ 
rw_inode(rip, WRITING); 
} 


break; 


case I_DIRECTORY: 
/* Diretórios podem ser lidos, mas não escritos. */ 
r = (bits & W_BIT ? EISDIR : OK); 
break; 


case I CHAR SPECIAL: 

case I BLOCK SPECIAL: 
/* Ativa o driver para processamento especial. */ 
dev = (dev t) rip->i zone[0]; 
r = dev open(dev, who, bits | (Coflags & “O ACCMODE)); 
break; 


case I NAMED PIPE: 
oflags |= O APPEND; /* força o modo de inclusão (append) */ 
fil ptr->filp flags = oflags; 
r = pipe open(lrip, bits, oflags); 
if Cr != ENXIO) 1 
/* Testa se alguém realiza uma leitura ou escrita na 
* FIFO. Se assim for, use sua entrada de filp para que a 
* posição do arquivo seja compartilhada automaticamente. 
* 
/ 
b = (bits &R BIT? R BIT: W BIT); 
fil ptr->filp count = 0; /* não se encontra */ 
if CCfilp2 = find filpCrip, b)) != NIL FILP) { 
/* Co-leitor ou escritor encontrado. Utiliza-o.*/ 
fp->fp filpIm in.fd] = filp2; 
filp2->filp count++; 
filp2->filpiino = rip; 
filp2->filp flags = oflags; 


/* à count foi incrementado incorretamente 
* por eatpath acima, não sabendo que 

* íamos usar uma entrada de 

* filp já existente. Corrige esse erro. 
*/ 


rip->i. count--; 
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24667 } else { 

24668 /* Ninguém mais encontrado. Restaura filp. */ 
24669 fil_ptr->filp_count = 1; 

24670 if Cb == R BIT) 

24671 pos = rip->i zone[V2 NR DZONES+0]; 
24672 else 

24673 pos = rip->i zone[V2 NR DZONES+1]; 
24674 fil ptr->filp pos = pos; 

24675 } 

24676 } 

24677 break; 

24678 } 

24679 J 

24680 } 

24681 

24682 /* Se houve erro, libera o i-node. */ 

24683 if Cr != OK) { 

24684 if (r == SUSPEND) return(r); /* Opa, apenas suspenso */ 
24685 fp->fp_filp[m_in.fd] = NIL_FILP; 

24686 fil_ptr->filp_count= 0; 

24687 put_inode(rip); 

24688 return(r); 

24689 } 

24690 

24691 return(m_in.fd); 

24692 } 


24694 /* === 
24695 ii new_node * 
24696 FOSSE SS SSIS SS DESSES DDS se / 
24697 PRIVATE struct inode *new node(char *path, mode t bits, zone t z0) 

24698 1 

24699 /* New node() é chamada por common open(), do mknod() e do mkdir. 


24700 Em todos os casos, ela aloca um novo i-node, faz uma entrada de diretório para ele no 
24701 * caminho "path" e o inicializa. Ela retorna um ponteiro para o i-node, caso 

24702 * possa fazer isso; caso contrário, retorna NIL INODE. Ela sempre configura "err code” 
24703 * com um valor apropriado (OK ou um código de erro). 

24704 */ 

24705 

24706 register struct inode *rlast dir ptr, *rip; 

24707 register int r; 

24708 char string[NAME MAX]; 

24709 

24710 /* Verifica se o caminho pode ser aberto até o último diretório. */ 


24711 if (Crlast dir ptr = last dirC(path, string)) == NIL INODE) return(NIL INODE); 
24712 


24713 /* O último diretório está acessível. Obtém o componente final do caminho. */ 

24714 rip = advance(rlast dir ptr, string); 

24715 if C rip == NIL INODE && err code == ENOENT) { 

24716 /* O último componente do caminho não existe. Faz uma nova entrada de diretório. */ 
24717 if C Crip = alloc inode(rlast dir ptr->i dev, bits)) == NIL INODE) 1 

24718 /* Não pode criar um novo i-node: falta de i-nodes. */ 

24719 put inode(rlast dir ptr); 

24720 return(NIL INODE); 

24721 } 

24722 

24723 /* Força o i-node no disco, antes de fazer uma entrada de diretório para tornar o 
24724 * sistema mais robusto perante uma falha: um i-node sem 

24725 * nenhuma entrada de diretório é muito melhor do que o contrário. 

24726 */ 
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24727 rip->i. nlinks++; 

24728 rip->i zone[0] = z0; /* números do dispositivo principal/secundário */ 
24729 rw inode(rip, WRITING); /* força o i-node no disco agora */ 
24730 

24731 /* Novo i-node adquirido. Tenta fazer entrada de diretório. */ 

24732 if (Cr = search dir(rlast dir ptr, string, &rip->i num, ENTER)) != OK) 1 
24733 put inode(rlast dir ptr); 

24734 rip->i nlinks--; /* pena, precisa liberar i-node do disco */ 
24735 rip->i dirt = DIRTY; /* os i-nodes sujos são escritos */ 
24736 put inode(rip); /* esta chamada libera o i-node */ 

24737 err code = r; 

24738 return(NIL INODE); 

24739 } 

24740 

24741 } else { 

24742 /* Ou o último componente existe ou há algum problema. */ 

24743 if Crip != NIL INODE) 

24744 r = EEXIST; 

24745 else 

24746 r = err code; 

24747 

24748 

24749 /* Retorna o i-node do diretório e sai. */ 


24750 put inode(Crlast dir ptr); 
24751 err code = r; 


24752 returnCrip); 

24753 } 

24755 — /*==== e 
24756 id pipe open * 
24757 foDocococoDcoDoDcocoDc=DcD=DDcDccDcocoDcDDeDcconccDcnconcncoDcncenc=n=n==== ¥ ) 
24758 PRIVATE int pipe open(register struct inode *rip, register mode t bits, 

24759 register int oflags) 

24760 { 

24761 /* Esta função é chamada a partir de common_open. Ela verifica se 

24762 * existe pelo menos um par leitor/escritor para o pipe; se não existir, 

24763 * ela suspende o processo que fez a chamada; caso contrário, reanima todos os outros 
24764 * processos bloqueados que estão presos no pipe. 

24765 F/ 

24766 


24767 rip->i pipe = I PIPE; 
24768 if Cfind filpCrip, bits & wW BIT? R BIT : W BIT) == NIL FILP) { 


24769 if Coflags & O NONBLOCK) 1 

24770 if (bits & W BIT) return(ENXIO); 

24771 } else { 

24772 suspend(XPOPEN) ; /* suspende o processo que fez a chamada */ 
24773 return (SUSPEND); 

24774 

24775 } else if (susp_count > 0) {/* reanima os processos bloqueados */ 

24776 release(rip, OPEN, susp_count); 

24777 release(rip, CREAT, susp_count); 

24778 } 

24779 return(0K); 

24780 } 

24782 J75 * 
24783 id do mknod * 
24784 Ss A 


24785 PUBLIC int do mknod() 
24786 {£ 
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24787 /* Executa a chamada de sistema mknod(name, mode, addr). */ 


24788 

24789 register mode t bits, mode bits; 

24790 struct inode *ip; 

24791 

24792 /* Apenas o super user pode fazer nós que não são fifos. */ 

24793 mode bits = (mode t) m in.mk mode; /* modo do i-node */ 

24794 if (!super user && ((mode bits & I TYPE) != I NAMED PIPE)) return(EPERM); 
24795 if (fetch name(m in.namel, m in.namel length, M1) != OK) return(err code); 
24796 bits = (mode bits & I TYPE) | (mode bits & ALL MODES & fp->fp umask); 

24797 ip = new node(user path, bits, (zone t) m in.mk Z0); 

24798 put inode(Cip); 

24799 return(err code); 

24800 + 

24802  /f=====D=">=DDD>00DD0 5050000000 DDD 
24803 E do mkdir * 
24804 FESESESESSSSESESSSDSSESSSAs=ESS SEE ESSES SSESSES 
24805 PUBLIC int do mkdir (O) 

24806 1 

24807 /* Executa a chamada de sistema mkdir (name, mode). */ 

24808 

24809 int r1, r2; /* códigos de status */ 

24810 ino_t dot, dotdot; /* números de i-node para . e .. */ 

24811 mode_t bits; /* bits de modo para o novo i-node */ 

24812 char string[NAME MAX]; /* último componente do nome de caminho do novo dir */ 
24813 register struct inode “rip, *ldirp; 

24814 

24815 /* Verifica se é possível fazer outro vínculo no diretório pai. */ 

24816 if (fetch_name(m_in.name1, m_in.namel_length, M1) != OK) return(err_code); 
24817 ldirp = last_dir(user_path, string); /* ponteiro para o pai do novo diretório */ 


24818 if Cldirp == NIL INODE) return(err code); 
24819 if Cldirp->i nlinks >= (ldirp->i sp->s version == V1 ? 


24820 CHAR MAX : SHRT MAX)) 1 

24821 put inode(ldirp); /* retorna o pai */ 

24822 return (EMLINK) ; 

24823 

24824 

24825 /* Em seguida, faz o i-node. Se isso falhar, retorna o código de erro. */ 
24826 bits = I DIRECTORY | (Cm in.mode & RWX MODES & fp->fp umask) ; 

24827 rip = new node(user path, bits, (zone t) 0); 

24828 if Crip == NIL INODE || err code == EEXIST) { 

24829 put inode(Crip); /* não pode fazer dir: já existe */ 

24830 put inode(ldirp); /* retorna o pai também */ 

24831 return(err code); 

24832 

24833 

24834 /* Obtém os números de i-node para . e .. para entrar no diretório. */ 
24835 dotdot = Tdirp->i num; /* número do i-node do pai */ 

24836 dot = rip->i num; /* número do i-node do próprio novo dir */ 
24837 

24838 /* Agora faz entradas para . e .., a menos que o disco esteja completamente cheio. */ 
24839 /* Usa dotl e dot2; portanto, o modo do diretório não é importante. */ 
24840 rip->i mode = bits; /* configura o modo */ 

24841 rl = search dir(rip, dot1, &dot, ENTER); /* insere . no novo dir */ 
24842 r2 = search dir(rip, dot2, &dotdot, ENTER); /* insere .. no novo dir */ 
24843 

24844 /* Se . e .. foram inseridos com sucesso, incrementa as contagens de vínculos. */ 


24845 if (rl == OK && r2 == OK) { 
24846 /* Caso normal. Foi possível inserir . e .. no novo dir. */ 
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24847 
24848 
24849 
24850 
24851 
24852 
24853 
24854 
24855 
24856 
24857 
24858 
24859 
24860 


24862 
24863 
24864 
24865 
24866 
24867 
24868 
24869 
24870 
24871 
24872 
24873 
24874 
24875 
24876 
24877 
24878 
24879 
24880 
24881 
24882 
24883 
24884 
24885 
24886 
24887 
24888 
24889 
24890 
24891 
24892 
24893 
24894 
24895 
24896 
24897 
24898 


24899 
24900 
24901 
24902 
24903 
24904 
24905 
24906 


rip->i nlinks++; /* isto é responsável por . */ 
Idirp->i nlinks++; /* isto é responsável por .. */ 
ldirp->i dirt = DIRTY; /* marca o i-node do pai como sujo */ 
} else { 
/* Não foi possível inserir . ou .., provavelmente o disco estava cheio. */ 


(void) search dir(ldirp, string, Cino t *) O, DELETE); 


rip->i nlinks--: /* desfaz o incremento feito em new nodeO */ 
} 
rip->i_dirt = DIRTY; /* de qualquer modo, i_nlinks mudou */ 
put_inode(ldirp); /* retorna o i-node do dir pai */ 
put_inode(rip); /* retorna o i-node do dir feito recentemente */ 
return(err_code); /* new node() sempre configura "err code” */ 
do close * 


PUBLIC int do close() 


{ 


/* 


Executa a chamada de sistema close(fd). */ 


register struct filp *rfilp; 
register struct inode *rip; 
struct file lock *flp; 

int rw, mode word, lock count; 
dev t dev; 


/* Primeiro localiza o i-node pertencente ao descritor de arquivo. */ 
if C Crfilp = get filpo(m in.fd)) == NIL FILP) return(err code); 
rip = rfilp->filp ino; /* "rip” aponta para o i-node */ 


if Crfilp->filp count - 1 == 0 && rfilp->filp mode != FILP CLOSED) { 
/* Verifica se o arquivo é especial. */ 
mode word = rip->i mode & I TYPE; 
if (mode word == I CHAR SPECIAL || mode word == I BLOCK SPECIAL) { 
dev = (dev t) rip->i zone[0]; 
if (mode word == I BLOCK SPECIAL) { 
/* Invalida as entradas da cache, a não ser que seja especial montado 
* ou ROOT 
*/ 
if (!mounted(rip)) { 
(void) do_syncO; /* expurga a cache */ 
invalidate(dev); 
} 
} 
/* Realiza todo processamento especial no fechamento do dispositivo. */ 
dev close(dev); 


} 


/* Se o i-node que está sendo fechado é um pipe, libera todos que estiverem presos 
nele. */ 
if Crip->i pipe == I_PIPE) { 
= (rfilp->filp_mode & R_BIT ? WRITE : READ); 
release(rip, rw, NR PROCS); 
} 


/* Se foi feita uma escrita, o i-node já está marcado como DIRTY. */ 
if (--rfilp->filp count == 0) { 
if Crip->i pipe == I_PIPE && rip->i_count > 1) { 
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24907 /* Salva a posição do arquivo no nó-I, para o caso de ser necessário 
24908 * posteriormente. As posições de leitura e escrita são salvas 
24909 * separadamente. As 3 últimas zonas no i-node não são usadas para pipes 
24910 * (nomeados). */ 

24911 if Crfilp->filp mode == R BIT) 

24912 rip->i zone[V2 NR DZONES+0] = (zone t) rfilp->filp pos; 
24913 else 

24914 rip->i zone[V2 NR DZONES+1] = (zone t) rfilp->filp pos; 
24915 } 

24916 put_inode(rip); 

24917 } 

24918 

24919 fp->fp cloexec &= “(IL << m_in.fd); /* desativa o bit de fechar ao executar */ 
24920 fp->fp_filp[m_in.fd] = NIL_FILP; 

24921 

24922 /* Verifica se o arquivo está travado. Se estiver, libera todas as travas */ 
24923 if (nr_locks == 0) return(0K); 

24924 lock count = nr_locks; /* salva a contagem das travas */ 

24925 for (flp = &file Tock[0]; flp < &file Tock[NR LOCKS]; flp++) { 

24926 if (flp->lock type == 0) continue; /* entrada que não está em uso */ 
24927 if Cflp->Tock inode == rip && flp->lock pid == fp->fp pid) { 

24928 flp->lock type = 0; 

24929 nr locks--; 

24930 } 

24931 } 

24932 if (nr_locks < lock_count) lock_revive(); /* trava liberada */ 

24933 return(0K); 

24934 } 

24936 /*===DDDDDDDDDDDDDDDDDDDDD0D0DDDDDDDD0D0DDDDDDDD02D0DDDDDDD>DDD=D=>=>=>>=>=>=>=>* 
24937 $ do_lseek * 
24938 ÉS SEDE / 
24939 PUBLIC int do Iseek() 

24940 1 


24941 /* Executa a chamada de sistema Iseek(lIs fd, offset, whence). */ 
24942 


24943 register struct filp *rfilp; 

24944 register off t pos; 

24945 

24946 /* Verifica se o descritor de arquivo é válido. */ 


24947 if C Crfilp = get filo(m in.ls fd)) == NIL FILP) return(err code); 
24948 

24949 /* Nada de Tseek em pipes. */ 

24950 if Crfilp->filp ino->i pipe == I PIPE) return(ESPIPE); 


24951 

24952 /* O valor de 'whence” determina a posição inicial a usar. */ 
24953 switch(m in.whence) { 

24954 case 0: pos = 0; break; 

24955 case 1: pos = rfilp->filp pos; break; 

24956 case 2: pos = rfilp->filp ino->i size; break; 

24957 default: return(EINVAL); 

24958 } 

24959 

24960 /* Verifica se houve estouro. */ 


24961 if (CClong)m_in.offset > 0) && ((Tong)(pos + m_in.offset) < (long)pos)) 
24962 return (EINVAL); 

24963 if (CClong)m_in.offset < 0) && ((Tong)(pos + m_in.offset) > (long)pos)) 
24964 return(EINVAL); 

24965 pos = pos + m in.offset; 

24966 
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24967 
24968 
24969 
24970 
24971 
24972 


APAE HH HHH HH H+H HH HH HHH HH HHHH HHHH H+ HHH H+H HHHH HHHH H+H+HH+HH+H+H+H+H+H+H+H+H+ 


HEHEHEHEH HHHH HHHH HHHH HH HH HH HHH H+H HHHH HHHH ++ 


25000 
25001 
25002 
25003 
25004 
25005 
25006 
25007 
25008 
25009 
25010 
25011 
25012 
25013 
25014 
25015 
25016 
25017 
25018 
25019 
25020 
25021 
25022 
25023 
25024 
25025 
25026 
25027 
25028 
25029 
25030 
25031 
25032 
25033 


25035 
25036 
25037 
25038 
25039 
25040 
25041 
25042 
25043 
25044 


if (pos != rfilp->filp_pos) 


rfilp->filp_ino->i_seek = ISEEK; 


rfilp->filp_pos = pos; 
m_out.reply_11 = pos; /* insere o valor long na mensagem de saída */ 
return(0K); 


/* Este arquivo contém o centro do mecanismo usado para ler (e escrever) 


servers/fs/read.c 


/* inibe a leitura antecipada */ 


* especiais também são detectadas e manipuladas. 


* Os pontos de entrada para este arquivo são 


do read: 
* read write: 
* read map: 


executa a chamada de sistema READ, chamando read write 
faz realmente o trabalho de READ e WRITE 
dado um i-node e a posição do arquivo, pesquisa seu número de zona 


* rd indir: lê uma entrada em um bloco indireto 
* read ahead: gerencia a leitura de bloco antecipada 
g4 

#include "fs.h" 

#include <fcnt1.h> 

#include <minix/com.h> 

#include "buf.h" 

#include "file.h" 

#include "fproc.h" 

#include "inode.h" 

#include "param.h" 

#include "super.h" 

FORWARD _PROTOTYPE(Ç( int rw chunk, (struct inode 


PUBLIC int do read() 
{ 


return(read_write(READING)) ; 


PUBLIC int read_write(rw_flag) 


int rw_flag; 


{ 


/* Executa a chamada de read(fd, buffer, nbytes) ou write(fd, buffer, nbytes). */ 


register struct inode *rip; 
register struct filp *f; 


*rip, off_t position, 


unsigned off, int chunk, unsigned left, int rw_flag, 
char *buff, int seg, int usr, int block_size, int *completed)); 


/* READING ou WRITING */ 


* arquivos. As requisições de leitura e escrita são divididas em trechos que não ultrapassam 
os limites do bloco. Então, cada trecho é processado por sua vez. As leituras em arquivos 
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25045 off t bytes left, f size, position; 


25046 unsigned int off, cum io; 
25047 int op, oflags, r, chunk, usr, seg, block spec, char spec; 
25048 int regular, partial pipe = 0, partial cnt = 0; 


25049 mode t mode word; 

25050 struct filp *wf; 

25051 int block size; 

25052 int completed, r2 = OK; 
25053 phys bytes p; 


25054 

25055 /* operações rw chunk() não terminadas restantes da chamada anterior! isso não pode 
25056 * acontecer. Isso significa que algo deu errado e não podemos reparar agora. 

25057 *y 

25058 if (bufs_in_use < 0) { 

25059 panic(_FILE__,"start - bufs in use negative", bufs in use); 

25060 

25061 

25062 /* O MM carrega os segmentos colocando coisas engraçadas nos 10 bits superiores de "fd". */ 
25063 if (who == PM PROC NR && (m in.fd & (CBYTED) ) É 

25064 usr =min.fd >> 7; 

25065 seg = (min.fd >> 5) & 03; 

25066 m_in.fd & 037; /* obtém o rid do usuário e dos bits de segmento */ 
25067 } else { 

25068 usr = who; /* caso normal */ 

25069 seg = D; 

25070 

25071 

25072 /* Se o descritor de arquivo é válido, obtém o i-node, o tamanho e o modo. */ 


25073 if (m in.nbytes < 0) return(EINVAL); 
25074 if (Cf = get filpC(m in.fd)) == NIL FILP) return(err code); 
25075 if (CCf->filp mode) & (rw flag == READING ? R BIT : W BITD) == 0) { 


25076 return(f->filp mode == FILP CLOSED ? EIO : EBADF); 

25077 } 

25078 if (m_in.nbytes == 0) 

25079 return(0); /* Arquivos de caractere especiais não precisam verificar 0*/ 
25080 

25081 /* verifica se o processo de usuário tem a memória que precisa. se não tiver, a 
25082 * cópia falhará posteriormente. Faz isso após a verifcação de O anterior, 

25083 * pois umap não quer fazer o mapeamento de O bytes. 

25084 */ 


25085 if (Cr = sys umap(usr, seg, (vir bytes) m in.buffer, m_in.nbytes, &p)) != OK) 
25086 return r; 

25087 position = f->filp pos; 

25088 oflags = f->filp flags; 

25089 rip = f->filp ino; 

25090 f size = rip->i size; 

25091 r=0K; 

25092 if Crip->i pipe == I PIPE) { 


25093 /* fp->fp cum io partial só é diferente de zero ao realizar escritas parciais */ 
25094 cum io = fp->fp cum io partial; 

25095 } else { 

25096 cum_io = 0; 

25097 F 


25098 op = (rw flag == READING ? DEV READ : DEV WRITE); 
25099 mode word = rip->i mode & I TYPE; 


25100 regular = mode word == I REGULAR || mode word == I NAMED PIPE; 
25101 

25102 if ((Cchar spec = (mode word == I CHAR SPECIAL ? 1: 0))) É 
25103 if (Crip->i zone[0] == NO DEV) 


25104 panic(. FILE ,"read write tries to read from 
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25105 
25106 
25107 
25108 
25109 
25110 
25111 
25112 
25113 
25114 
25115 
25116 
25117 
25118 
25119 
25120 
25121 
25122 
25123 
25124 
25125 
25126 
25127 
25128 
25129 
25130 
25131 
25132 
25133 
25134 
25135 
25136 
25137 
25138 
25139 
25140 
25141 
25142 
25143 
25144 
25145 
25146 
25147 
25148 
25149 
25150 
25151 
25152 
25153 
25154 
25155 
25156 
25157 
25158 
25159 
25160 
25161 
25162 
25163 
25164 


"caractere device NO DEV", NO NUM); 
block size = get block size(rip->i zone[01]); 
} 
if ((block_spec = (mode word == I BLOCK SPECIAL ? 1 : 0))) {í 
f_size = ULONG_MAX; 
if (Crip->i zone[0] == NO DEV) 
panic(. FILE ,"read write tries to read from 
" block device NO DEV", NO NUM); 
block size = get block size(rip->i zone[01); 


} 


if (!char_spec && !block_spec) 
block size = rip->i sp->s block size; 


rdwt err = OK; /* configura como EIO se ocorrer erro de disco */ 


/* Verifica a existência de arquivos de caractere especiais. */ 
if (char spec) { 
dev t dev; 
dev = (dev t) rip->i zone[0]; 
r = dev iolop, dev, usr, m in.buffer, position, m in.nbytes, oflags); 


if (r >= 0) 1 
cum io = r; 
position += r; 
r= OK; 
} 
} else { 


if Crw flag == WRITING && block spec == 0) { 
/* Testa antes para ver se o arquivo vai ficar grande demais. */ 
if (position > rip->i sp->s max size - m in.nbytes) 
return(EFBIG); 


/* Verifica for O APPEND flag. */ 
if Coflags & O APPEND) position = f size; 


/* Limpa a zona que contém o EOF presente, se uma lacuna estiver 
* para ser criada. Isso é necessário porque todos os blocos 

* não escritos antes do EOF devem ser lidos como zeros. 

*/ 

if (position > f_size) clear_zone(rip, f_size, 0); 


} 


/* Os pipes são um pouco diferentes. Verifica. */ 
if Crip->i pipe == I_PIPE) { 
r = pipe_check(rip, rw_flag, oflags, 
m_in.nbytes, position, &partial_cnt, 0); 
if (r <= 0) return(r); 
} 


if (partial cnt > 0) partial pipe = 1; 


/* Divide a transferência em trechos que não abrangem dois blocos. */ 
while (m in.nbytes != 0) 1 


off = (unsigned int) (position % block size);/* deslocamento no blc*/ 
if (partial pipe) { /* somente para pipes */ 
chunk = MINCpartial cnt, block size - off); 
+ else 
chunk = MINCm in.nbytes, block size - off); 
if (chunk < 0) chunk = block size - off; 
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25165 
25166 
25167 
25168 
25169 
25170 
25171 
25172 
25173 
25174 
25175 
25176 
25177 
25178 
25179 
25180 
25181 
25182 
25183 
25184 
25185 
25186 
25187 
25188 
25189 
25190 
25191 
25192 
25193 
25194 
25195 
25196 
25197 
25198 
25199 
25200 
25201 
25202 
25203 
25204 
25205 
25206 
25207 
25208 
25209 
25210 
25211 
25212 
25213 
25214 
25215 
25216 
25217 
25218 
25219 
25220 
25221 
25222 
25223 
25224 


if Crw flag == READING) 1 
bytes left = f size - position; 
if (position >= f size) break; /* estamos além de EOF */ 
if (chunk > bytes left) chunk = (int) bytes left; 

} 

/* Lê ou escreve "chunk” bytes. */ 

r = rw chunk(rip, position, off, chunk, (unsigned) m in.nbytes, 


rw flag, m in.buffer, seg, usr, block size, &completed); 


if (r != OK) break; /* EOF atingido */ 
if (rdwt err < 0) break; 


/* Atualiza contadores e ponteiros. */ 


min.buffer += chunk; /* endereço de buffer de usuário */ 
m in.nbytes -= chunk; /* bytes ainda a serem lidos */ 

cum io += chunk; /* bytes lidos até aqui */ 

position += chunk; /* posição dentro do arquivo */ 


if (partial pipe) { 
partial cnt -= chunk; 
if (partial cnt <= 0) break; 


} 


/* Na escrita, atualiza o tamanho e o tempo de acesso do arquivo. */ 
if Crw flag == WRITING) { 
if (regular || mode word == I_DIRECTORY) { 
if (position > f_size) rip->i_size = position; 
} 
} else { 
if Crip->i pipe == I_PIPE) { 
if (C position >= rip->i_size) { 
/* Reconfigura ponteiros de pipe. */ 
rip->i_size = 0; /* não restam dados */ 
position = 0; /* reconfigura leitor(es) */ 
wf = find filpCrip, W BIT); 
if (wf != NIL FILP) wf->filp pos = 0; 


} 
} 


f->filp_pos = position; 


/* Verifica se é necessária leitura antecipada e, se for, a configura. */ 
if (rw flag == READING && rip->i_seek == NO SEEK && position % block size== 
&& (regular || mode word == I DIRECTORY)) { 
rdahed inode = rip; 
rdahedpos = position; 
} 
rip->i_seek = NO_SEEK; 


if (rdwt_err != OK) r = rdwt_err; /* verifica a existência de erro de disco */ 
if (rdwt_err == END OF FILE) r = OK; 


/* se a cópia do espaço de usuário falhou, a leitura/escrita falhou. */ 
if (r == OK & r2 != OK) { 
t= r2; 


} 
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25225 
25226 
25227 
25228 
25229 
25230 
25231 
25232 
25233 
25234 
25235 
25236 
25237 
25238 
25239 
25240 
25241 
25242 
25243 
25244 
25245 
25246 


25248 
25249 
25250 
25251 
25252 
25253 
25254 
25255 
25256 
25257 
25258 
25259 
25260 
25261 
25262 
25263 
25264 
25265 
25266 
25267 
25268 
25269 
25270 
25271 
25272 
25273 
25274 
25275 
25276 
25277 
25278 
25279 
25280 
25281 
25282 
25283 
25284 


if (Cr == 0K) É 
if Crw flag == READING) rip->i update |= ATIME; 
if Crw flag == WRITING) rip->i update |= CTIME | MTIME; 
rip->i dirt = DIRTY; /* assim, o i-node está sujo agora */ 
if (partial pipe) { 
partial pipe = 0; 
/* escrita parcial no pipe com */ 
/* O NONBLOCK, retorna a contagem de escrita */ 
if (U(oflags & O NONBLOCK)) 1 
fp->fp cum io partial = cum io; 
suspend(XPIPE); /* escrita parcial no pipe com */ 
return(SUSPEND); /* nbyte > PIPE SIZE - não-atômico */ 
} 
} 
fp->fp_cum_io_partial = 0; 
return(cum_io); 


} 
if (bufs_in_use < 0) { 
panic(_FILE__,"end - bufs_in_use negative", bufs in use); 
} 
return(r); 
} 
JŽ ======== * 
hd rw chunk * 
dED======D==2>=>>=>>=>>>=>>=>>=>>=>>>>>=>>>>>>>>=>>>>>=>>=>>=>>>>>>>>=>=>>=>=>=>>=>==>>=>=>==== * / 


PRIVATE int rw chunkCrip, position, off, chunk, left, rw flag, buff, 
seg, usr, block size, completed) 


register struct inode “rip; /* ponteiro para i-node do arquivo a ser lTido/escrito */ 
off t position; /* posição dentro do arquivo a ler ou escrever */ 
unsigned off; /* deslocamento dentro do bloco corrente */ 

int chunk; /* número de bytes a ler ou escrever */ 

unsigned left; /* número max de bytes solicitados após a posição */ 
int rw flag; /* READING ou WRITING */ 

char *buff; /* endereço virtual do buffer de usuário */ 

int seg; /* segmento T ou D no espaço de usuário */ 

int usr; /* qual processo de usuário */ 

int block size; /* tamanho de bloco do FS em que se está operando */ 
int *completed; /* número de bytes copiados */ 


{ 


/* Lê ou escreve (parte de) um bloco. */ 


register struct buf *bp; 
register int r = OK; 

int n, block_spec; 
block_t b; 

dev_t dev; 


*completed = 0; 


block_spec = (rip->i_mode & I_TYPE) == I_BLOCK_SPECIAL; 
if (block_spec) { 

b = position/block_size; 

dev = (dev_t) rip->i_zone[0]; 
} else { 

b = read_map(rip, position); 

dev = rip->i_dev; 


} 


if (!block_spec && b == NO BLOCK) { 
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25285 if Crw flag == READING) { 

25286 /* Lendo de um bloco inexistente. Deve ler tudo como zero. */ 
25287 bp = get block(NO DEV, NO BLOCK, NORMAL); /* obtém um buffer */ 
25288 zero block(bp); 

25289 } else { 

25290 /* Escrevendo em um bloco inexistente. Cria e entra no i-node.*/ 
25291 if ((bp= new_block(rip, position)) == NIL_BUF)return(err_code); 
25292 } 

25293 } else if (rw flag == READING) { 

25294 /* Leitura e leitura antecipada, se for conveniente. */ 

25295 bp = rahead(rip, b, position, left); 

25296 } else { 

25297 /* Normalmente, um bloco já existente a ser sobrescrito parcialmente primeiro é 
25298 * lido. Entretanto, um bloco cheio não precisa ser lido. Se ele já está na 
25299 * cache, o adquire; caso contrário, apenas adquire um buffer livre. 
25300 */ 

25301 n = (chunk == block size ? NO READ : NORMAL); 

25302 if (C!block spec && off == 0 && position >= rip->i size) n = NO READ; 
25303 bp = get block(dev, b, n); 

25304 } 

25305 

25306 /* Em todos os casos, bp aponta agora para um buffer válido. */ 

25307 if (bp == NIL_BUF) { 

25308 panic(__FILE__,"bp not valid in rw_chunk, this can’t happen", NO NUM); 
25309 } 

25310 if Crw flag == WRITING && chunk != block size && !block_spec && 

25311 position >= rip->i size && off == 0) { 
25312 zero block(bp); 

25313 

25314 

25315 if (rw flag == READING) 1 

25316 /* Copia um trecho do buffer de bloco no espaço de usuário. */ 

25317 r = sys vircopy(FS PROC NR, D, Cphys bytes) (bp->b data+off), 

25318 usr, seg, (phys bytes) buff, 

25319 Cphys bytes) chunk); 

25320 } else { 

25321 /* Copia um trecho do espaço de usuário no buffer de bloco. */ 

25322 r = sys vircopy(usr, seg, (phys bytes) buff, 

25323 FS PROC NR, D, (phys bytes) (bp->b data+off), 

25324 Cphys bytes) chunk); 

25325 bp->b dirt = DIRTY; 

25326 


25327 n = (off + chunk == block size ? FULL DATA BLOCK : PARTIAL DATA BLOCK); 
25328 put bTockCbp, n); 


25329 

25330 return(r); 

25331 + 

25334 /f======D=D=D5D55D5D=DDDDDDDDD2DDDDDDDD2D2DDD=D==2==>=>==>====================== * 

25335 x read map * 

25336 PEDE ade / 

25337 PUBLIC block t read map(rip, position) 

25338 register struct inode *rip; /* ptr a partir do qual o i-node deve fazer o mapeamento */ 
25339 off t position; /* posição no arquivo cujo blc foi solicitado */ 

25340 { 

25341 /* Dados um i-node e uma posição dentro do arquivo correspondente, localiza 

25342 * o número do bloco (e não da zona) em que essa posição deve ser encontrada e o retorna. 
25343 #7 
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25345 
25346 
25347 
25348 
25349 
25350 
25351 
25352 
25353 
25354 
25355 
25356 
25357 
25358 
25359 
25360 
25361 
25362 
25363 
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25365 
25366 
25367 
25368 
25369 
25370 
25371 
25372 
25373 
25374 
25375 
25376 
25377 
25378 
25379 
25380 
25381 
25382 
25383 
25384 
25385 
25386 
25387 
25388 
25389 
25390 
25391 
25392 
25393 
25394 
25395 


25397 
25398 
25399 
25400 
25401 
25402 
25403 
25404 


register struct buf *bp; 

register zone t Z; 

int scale, boff, dzones, nr indirects, index, zind, ex; 
block t b; 

long excess, zone, block pos; 


scale = rip->i sp->s log zone size; /* para conversão de bloco em zona */ 
block pos = position/rip->i sp->s block size; /* número do bloco relativo no arquivo */ 
zone = block pos >> scale; /* zona da posição */ 


boff = (int) (block pos - (zone << scale) ); /* nr. do bloco relativo dentro da zona */ 
dzones = rip->i ndzones; 
nr indirects = rip->i nindirs; 


/* A "posição" deve ser encontrada no próprio i-node? */ 
if (zone < dzones) { 
zind = (int) zone; /* o índice deve ser um int */ 
z = rip->i zone[zind]; 
if (z == NO ZONE) return(NO BLOCK); 
b = ((block t) z << scale) + boff; 
return(b); 
} 


/* Não está no i-node; portanto, deve ser indireto simples ou duplo. */ 
excess = zone - dzones; /* as primeiras Vx NR DZONES não contam */ 


if (excess < nr indirects) { 
/* a "posição" pode ser localizada por meio do bloco de indireção simples. */ 
z = rip->i zone[dzones]; 
} else { 
/* a "posição" pode ser localizada por meio do bloco indireção dupla. */ 
if C (z = rip->i zone[dzones+1]) == NO ZONE) return(NO BLOCK); 
excess -= nr indirects; /* indireto simples não conta */ 
b = (block t) z << scale; 
bp = get block(rip->i dev, b, NORMAL); /* obtém bloco indireção dupla */ 
index = (int) (excess/nr indirects); 


z = rd indir(bp, index); /* z= zona para simples */ 
put bTock(bp, INDIRECT BLOCK); /* libera bloco ind dupla */ 
excess = excess % nr indirects; /* índice para bloco ind simples */ 


} 


/* °z? é o número da zona do bloco de indireção simples; ’excess’ é o índice para ele. */ 
if (z == NO ZONE) return(NO BLOCK); 


b = (block t) z << scale; /* b é o nr. do bloco para ind simples */ 
bp = get blockCrip->i dev, b, NORMAL); /* obtém bloco de indireção simples */ 
ex = (int) excess; /* precisa de um inteiro */ 

z = rd indir(bp, ex); /* obtém bloco apontado */ 

put block(bp, INDIRECT BLOCK); /* libera bloco indir simples */ 


if (z == NO ZONE) return(NO BLOCK); 
b = ((block t) z << scale) + boff; 


return(b); 

} 

/* === ¥ 
é rd indir i 
a / 

PUBLIC zone_t rd_indir(bp, index) 

struct buf *bp; /* ponteiro para bloco indireto */ 

int index; /* índice para *bp */ 

{ 


/* Dado um ponteiro para um bloco indireto, lê uma entrada. O motivo de 
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25405 
25406 
25407 
25408 
25409 
25410 
25411 
25412 
25413 
25414 
25415 
25416 
25417 
25418 
25419 
25420 
25421 
25422 
25423 
25424 
25425 
25426 
25427 


25429 
25430 
25431 
25432 
25433 
25434 
25435 
25436 
25437 
25438 
25439 
25440 
25441 
25442 
25443 
25444 
25445 
25446 


25448 
25449 
25450 
25451 
25452 
25453 
25454 
25455 
25456 
25457 
25458 
25459 
25460 
25461 
25462 
25463 
25464 


* fazer uma rotina separada para isso é que existem quatro casos: 
* V1 (IBM e 68000) e V2 (IBM e 68000). 


*/ 

struct super block *sp; 

zone t zone; /* as zonas do V2 são valores long (short no V1) */ 
sp = get super(bp->b dev); /* Usa superbloco para obter tipo de sist. de arquivos 


/* Tê uma zona de um bloco indireto */ 
if (sp->s version == V1) 

zone = (zone t) conv2(sp->s native, (int) bp->b v1 ind[index1); 
else 

zone = (zone t) conv4(sp->s native, (long) bp->b v2 ind[index]); 


if (zone != NO ZONE && 
(zone < (zone t) sp->s firstdatazone || zone >= sp->s zones)) { 
printf("Illegal zone number %ld in indirect block, index %d\n", 
(long) zone, index); 
panic(. FILE ,"check file system", NO NUM); 


} 
return(zone); 
} 
J a a >>. * 
* read ahead * 
X CODSDSSSSSSSSDSSDSSSD=D===================================================== * / 
PUBLIC void read ahead() 
{ 
/* Lê um bloco na cache antes que ele seja necessário. */ 
int block_size; 
register struct inode *rip; 
struct buf *bp; 
block_t b; 
rip = rdahed_inode; /* ponteiro i-node de onde fazer a leitura antecipada */ 


block_size = get_block_size(rip->i_dev); 

rdahed_inode = NIL_INODE; /* desativa a leitura antecipada */ 

if C (b = read_map(rip, rdahedpos)) == NO BLOCK) return; /* no EOF */ 
bp = rahead(rip, b, rdahedpos, block_size); 

put_block(bp, PARTIAL DATA BLOCK); 


PUBLIC struct buf *rahead(rip, baseblock, position, bytes ahead) 


register struct inode *rip; /* ponteiro para i-node do arquivo a ser lido */ 
block t baseblock; /* bloco na posição corrente */ 

off t position; /* posição dentro do arquivo */ 

unsigned bytes ahead; /* bytes além da posição para uso imediato */ 

{ 


/* Busca um bloco da cache ou do dispositivo. Se for exigida uma leitura 
* física, busca previamente tantos mais blocos quantos forem convenientes na cache. 
* Isso normalmente cobre bytes_ahead e é de pelo menos BLOCKS_MINIMUM. 
* O driver de dispositivo pode decidir que sabe mais e parar de ler em um 
* limite de cilindro (ou após um erro). Rw_scattered() coloca um flag 
* opcional em todas as leituras para permitir isso. 
7d 


int block size; 
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25465 
25466 
25467 
25468 
25469 
25470 
25471 
25472 
25473 
25474 
25475 
25476 
25477 
25478 
25479 
25480 
25481 
25482 
25483 
25484 
25485 
25486 
25487 
25488 
25489 
25490 
25491 
25492 
25493 
25494 
25495 
25496 
25497 
25498 
25499 
25500 
25501 
25502 
25503 
25504 
25505 
25506 
25507 
25508 
25509 
25510 
25511 
25512 
25513 
25514 
25545 
25516 
25517 
25518 
25519 
25520 
25521 
25522 
25523 
25524 


/* Número mínimo de blocos a serem buscados previamente. */ 
# define BLOCKS_MINIMUM (NR BUFS < 50 ? 18 : 32) 

int block_spec, scale, read_q_size; 

unsigned int blocks_ahead, fragment; 

block_t block, blocks_left; 

off_t indl pos; 

dev t dev; 

struct buf *bp; 

static struct buf *read q[NR BUFS]; 


block spec = (rip->i mode & I TYPE) == I BLOCK SPECIAL; 
if (block speco) 1 
dev = (dev t) rip->i zone[0]; 
} else { 
dev = rip->i_dev; 
} 


block_size = get_block_size(dev); 


block = baseblock; 
bp = get_block(dev, block, PREFETCH) ; 
if (bp->b_dev != NO_DEV) return(bp); 


/* A melhor aposta para o número de blocos a serem buscados previamente: muitos. 
* E impossível saber como é o dispositivo; portanto, nem mesmo 
* tentamos adivinhar a geometria, mas deixamos isso para o driver. 


* O driver de disquete pode ler uma trilha inteira sem nenhum atraso rotacional e evita 
* a leitura de trilhas parciais, se puder; portanto, dar a ele buffers suficientes para 
* ler duas trilhas é perfeito. (Dois, porque alguns tipos de disquete têm um número 

* ímpar de setores por trilha, de modo que um bloco pode abranger mais de uma trilha.) 


* Os drivers de disco não tentam ser espertos. Com os discos de hoje é 

* impossível dizer como é a geometria real; portanto, é melhor 

* Ter o máximo que você puder. Com sorte, o uso de cache na unidade de disco 
* permite iniciar a próxima leitura, por pouco tempo. 


* A solução atual a seguir é um pouco forçada, ela apenas lê blocos da 

* posição corrente do arquivo, esperando que mais posições possam ser encontradas. Uma 
* solução melhor deve examinar os ponteiros de zona e 

* bloco indiretos já disponíveis (mas não chamar read map!). 


fragment = position % block size; 
position -= fragment; 
bytes ahead += fragment; 


blocks ahead = (bytes ahead + block size - 1) / block size; 


if (block spec && rip->i size == 0) 1 
blocks left = NR IOREQS; 
} else { 
blocks_left = (rip->i_size - position + block_size - 1) / block_size; 


/* Vai para o primeiro bloco indireto, caso estejamos em sua vizinhança. */ 
if (!block spec) 1 
scale = rip->i sp->s log zone size; 
indl pos = (off t) rip->i ndzones * (block size << scale); 
if (position <= indl pos & rip->i size > indl pos) { 
blocks ahead++; 
blocks Teft++; 
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25525 5 

25526 } 

25527 } 

25528 

25529 /* Não mais do que a requisição máxima. */ 


25530 if (blocks_ahead > NR_IOREQS) blocks_ahead = NR_IOREQS; 
25531 


25532 /* Lê pelo menos o número mínimo de blocos, mas não após uma busca. */ 
25533 if (blocks_ahead < BLOCKS_MINIMUM && rip->i_seek == NO_SEEK) 

25534 blocks ahead = BLOCKS MINIMUM; 

25535 

25536 /* Não pode ultrapassar o final do arquivo. */ 


25537 if (blocks ahead > blocks left) blocks ahead = blocks left; 
25538 

25539 read q size = 0; 

25540 

25541 /* Adquire buffers de bloco. */ 

25542 for GG) -£ 


25543 read qlread q size++] = bp; 

25544 

25545 if (--blocks ahead == 0) break; 

25546 

25547 /* Não joga a cache fora, deixa 4 livres. */ 
25548 if (Cbufs in use >= NR BUFS - 4) break; 

25549 

25550 block++; 

25551 

25552 bp = get block(dev, block, PREFETCH) ; 

25553 if (bp->b dev != NO DEV) 1 

25554 /* Opa, o bloco já está na cache, sai. */ 
25555 put block(bp, FULL DATA BLOCK); 
25556 break; 

25557 } 

25558 } 

25559 rw_scattered(dev, read q, read q size, READING); 
25560 return(get block(dev, baseblock, NORMAL)); 

25561 3 


AAA 
servers/fs/write.c 
HHHEHEHHHHHHH EHEHEH HHHH HHHH HHHH HHH HHHH HHHH HHHH O O DD H+H O O O DO OO OO O O 


25600 /* Este arquivo é o complemento de "read.c”. Ele contém o código para escrita 


25601 * que não está contido em read write(). 

25602 + 

25603 * Os pontos de entrada para este arquivo são 

25604 * do write: chama read write para executar a chamada de sistema WRITE 
25605 * clear zone: apaga uma zona no meio de um arquivo 

25606 E new block: adquire um novo bloco 

25607 */ 

25608 


25609 include "fs.h" 
25610 #include <string.h> 
25611 #include "buf.h" 
25612 #include "file.h" 
25613 #include "fproc.h" 
25614 #include "inode.h" 
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25615 
25616 
25617 
25618 
25619 
25620 
25621 
25622 
25623 
25624 
25625 
25626 
25627 
25628 
25629 
25630 


25632 
25633 
25634 
25635 
25636 
25637 
25638 
25639 
25640 
25641 
25642 
25643 
25644 
25645 
25646 
25647 
25648 
25649 
25650 
25651 
25652 
25653 
25654 
25655 
25656 
25657 
25658 
25659 
25660 
25661 
25662 
25663 
25664 
25665 
25666 
25667 
25668 
25669 
25670 
25671 
25672 
25673 
25674 


tinclude "super.h" 


FORWARD | PROTOTYPE( int write map, (struct inode “rip, off t position, 
zone t new zone) J3 


FORWARD | PROTOTYPE( void wr indir, (struct buf *bp, int index, zone t zone) ); 


/f=============>>=>=====>>>>>>=>>>=>>>=>>>>>>==>>>>>>>==>>>=>>>>=>====>>======== * 
i do_write * 
$ J222 */ 

PUBLIC int do write() 

{ 


/* Executa a chamada de sistema write(fd, buffer, nbytes). */ 


return(read_write(WRITING)); 


* write map 


PRIVATE int write map(rip, position, new zone) 


register struct inode “rip; /* ponteiro para o i-node a ser alterado */ 
off t position; /* endereço de arquivo a ser mapeado */ 
zone t new zone; /* número da zona a ser inserida */ 


{ 
/* Escreve uma nova zona em um i-node. */ 
int scale, ind ex, new ind, new_dbl, zones, nr_indirects, single, zindex, ex; 
zone t z, z1; 
register block t b; 
long excess, zone; 
struct buf *bp; 


rip->i dirt = DIRTY; /* o i-node será alterado */ 
bp = NIL BUF; 
scale = rip->i sp->s log zone size; /* para conversão de zona em bloco */ 


/* relative zone # to insert */ 
zone = (position/rip->i sp->s block size) >> scale; 
zones = rip->i ndzones; /* número de zonas diretas no i-node */ 
nr indirects = rip->i nindirs;/* número de zonas indiretas por bloco indireto */ 


/* A "posição" a ser encontrada está no próprio i-node? */ 
if (zone < zones) { 


zindex = (int) zone; /* precisamos de um inteiro aqui */ 
rip->i_zone[zindex] = new_zone; 
return(0K); 


} 


/* Ela não está no i-node; portanto, deve ser indireta simples ou dupla. */ 
excess = zone - zones; /* as primeiras Vx_NR_DZONES não contam aquii */ 
new_ind = FALSE; 

new_dbl = FALSE; 


if (excess < nr_indirects) { 


/* a "posição" pode ser localizada por meio do bloco de indireção simples. */ 


zl = rip->i zone[zones]; /* zona indireta simples */ 
single = TRUE; 
} else { 


/* a "posição" pode ser localizada por meio do bloco de indireção dupla. */ 
if (C (z = rip->i_zone[zones+1]) == NO ZONE) { 
/* Cria o bloco de indireção dupla. */ 
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25675 if C (z = alloc zone(rip->i dev, rip->i zone[0])) == NO ZONE) 

25676 return(err code); 

25677 rip->i zone[zones+1] = z; 

25678 new dbl = TRUE; /* ativa flag para mais tarde */ 

25679 

25680 

25681 /* De qualquer modo, 'z' é o número de zona do bloco de indireção dupla. */ 
25682 excess -= nr indirects; /* indireção simples não conta */ 

25683 ind ex = (int) (excess / nr indirects); 

25684 excess = excess % nr indirects; 

25685 if Cind ex >= nr indirects) return(EFBIG); 

25686 b = (block t) z << scale; 

25687 bp = get block(rip->i dev, b, (new dbl ? NO READ : NORMAL)); 

25688 if (new db1T) zero block(Cbp); 

25689 zl = rd indir(bp, ind ex); 

25690 single = FALSE; 

25691 

25692 

25693 /* z1 agora é uma zona indireção simples; 'excess' é o índice. */ 

25694 if (z1 == NO ZONE) { 

25695 /* Cria bloco indireto e armazena o nº da zona no i-node ou bloco de ind. dupla. */ 
25696 zl = alloc zone(rip->i dev, rip->i zone[01]); 

25697 if (single) 

25698 rip->i zone[zones] = z1; /* atualiza o i-node */ 

25699 else 

25700 wr indir(bp, ind ex, z1); /* atualiza indireção dupla */ 
25701 

25702 new ind = TRUE; 

25703 if (bp != NIL BUF) bp->b dirt = DIRTY; /* se é indireção dupla, ele está sujo */ 
25704 if (z1 == NO ZONE) 1 

25705 put block(bp, INDIRECT BLOCK);  /* libera bloco de indireção dupla */ 
25706 return(err code); /* não pode criar indireção simples */ 
25707 

25708 

25709 put block(bp, INDIRECT BLOCK); /* libera bloco de indireção dupla */ 
25710 

25711 /* z1 é o número de zona do bloco indireto. */ 


25712 b = (block t) z1 << scale; 

25713 bp = get blockCrip->i dev, b, (new ind ? NO READ : NORMAL) ); 

25714 if (new ind) zero block(bp); 

25715 ex = (int) excess; /* precisamos de um int aqui */ 
25716 wr indir(bp, ex, new zone); 

25717 bp->b dirt = DIRTY; 

25718 put block(bp, INDIRECT BLOCK); 


25719 

25720 return(OK); 

25721 } 

25723 

25724 * wr indir * 
25725 CEE E e E 
25726 PRIVATE void wr indir(bp, index, zone) 

25727 struct buf *bp; /* ponteiro para bloco indireto */ 

25728 int index; /* índice para *bp */ 

25729 zone t zone; /* zona a escrever */ 

25730 { 


25731 /* Dado um ponteiro para um bloco indireto, escreve uma entrada. */ 
25732 

25733 struct super block *sp; 

25734 
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sp = get super(bp->b dev); /* precisa do superbloco para descobrir o tipo do FS */ 


/* escreve uma zona em um bloco indireto */ 
if (sp->s version == V1) 

bp->b v1 ind[index] = (zonel t) conv2(sp->s native, (int) zone); 
else 

bp->b v2 ind[index] = (zone t) conv4(sp->s native, (long) zone); 


} 
/ TE e  —.————.—.—————————————— 
* clear zone * 
ki D===========>=>=>>=>=>>=>>=>=>>=>>>=>>=>=>>=>=>>>>>=>>>>=>=>>>=>>>>=>>=>>=>>=>=>==>>=>>======= * / 
PUBLIC void clear zone(rip, pos, flag) 
register struct inode “rip; /* i-node a limpar */ 
off t pos; /* aponta para o bloco a limpar */ 
int flag; /* O if called by read write, 1 by new block */ 
{ 


/* Zera uma zona, possivelmente começando no meio. O parâmetro "pos" fornece 
* um byte no primeiro bloco a ser zerado. Clearzone() é chamada a partir de 
* read write e de new block(). 


*/ 


register struct buf *bp; 
register block_t b, blo, bhi; 
register off_t next; 

register int scale; 

register zone_t zone_size; 


/* Se o tamanho do bloco e da zona forem iguais, clear zone() não é necessária. */ 
scale = rip->i sp->s log zone size; 
if (scale == 0) return; 


zone size = (zone t) rip->i sp->s block size < scale; 
if (flag == 1) pos = (pos/zone size) * zone size; 
next = pos + rip->i sp->s block size - 1; 


/* Se "pos" está no último bloco de uma zona, não limpa a zona. */ 
if (next/zone size != pos/zone size) return; 

if C (blo = read map(rip, next)) == NO BLOCK) return; 

bhi = ( ((blo>>scale)+1) << scale) - 1; 


/* Limpa todos os blocos entre "blo” e "bhi”. */ 
for (b = blo; b <= bhi; bw) { 
bp = get_block(rip->i_dev, b, NO READ); 
zero_block(bp); 
put_block(bp, FULL DATA BLOCK); 


} 
} 
Jin 
* new block * 
X Se= * / 
PUBLIC struct buf *new block(rip, position) 
register struct inode “rip; /* ponteiro para o i-node */ 
off t position; /* ponteiro de arquivo */ 
{ 


/* Adquire um novo bloco e retorna um ponteiro para ele. Fazer isso pode exigir 
* a alocação de uma zona completa e, então, o retorno do bloco inicial. 
* Por outro lado, a zona corrente ainda pode ter alguns blocos não utilizados. 


*/ 
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25795 
25796 
25797 
25798 
25799 
25800 
25801 
25802 
25803 
25804 
25805 
25806 
25807 
25808 
25809 
25810 
25811 
25812 
25813 
25814 
25815 
25816 
25817 
25818 
25819 
25820 
25821 
25822 
25823 
25824 
25825 
25826 
25827 
25828 
25829 
25830 
25831 
25832 
25833 
25834 


25836 
25837 
25838 
25839 
25840 
25841 
25842 
25843 
25844 
25845 


register struct buf *bp; 
block t b, base block; 
zone t Z; 

zone t zone size; 

int scale, r; 

struct super block *sp; 


/* Outro bloco está disponível na zona corrente? */ 
if C (b = read map(lrip, position)) == NO BLOCK) 1 
/* Escolhe a primeira zona, se possível. */ 


/* Perde se o arquivo não está vazio, mas o número da primeira zona é NO ZONE, 


* correspondendo a uma zona cheia de zeros. Seria melhor 
* pesquisar próximo à última zona real. 

*/ 

if Crip->i_zone[0] == NO ZONE) { 

sp = rip->i_sp; 

z = sp->s_firstdatazone; 


} else { 
z = rip->i_zone[0]; /* procura próximo à primeira zona */ 
} 
if (C (z = alloc_zone(rip->i_dev, z)) == NO ZONE) return(NIL_BUF); 
if C (r = write_map(rip, position, z)) != OK) { 


free_zone(rip->i_dev, z); 
err_code = r; 
return(NIL_BUF); 


/* Se não estamos escrevendo em EOF, limpa a zona, apenas por segurança. */ 
if (C position != rip->i_size) clear_zone(rip, position, 1); 

scale = rip->i_sp->s_log_zone_size; 

base_block = (block_t) z << scale; 

zone_size = (zone_t) rip->i_sp->s_block_size << scale; 

b = base_block + (block_t)((position % zone_size)/rip->i_sp->s_block_size); 


} 


bp = get_block(rip->i_dev, b, NO READ); 
zero_block(bp); 


return(bp); 
} 
/ À ni a TE E TT... E 
* zero block * 
de e = na RE E RR E, 
PUBLIC void zero block(bp) 
register struct buf *bp; /* ponteiro para buffer a zerar */ 
{ 


/* Zero a block. */ 
memset(bp->b data, O, MAX BLOCK SIZE); 
bp->b dirt = DIRTY; 

} 
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AAA 
servers/fs/pipe.c 
HHHHHHHHHHHHH HHHH HHHH HHHH HHHH HHHH EO OS O O O O O O DD H+ O O O DO OO OD O O 


25900 /* Este arquivo trata da suspensão e da reanimação de processos. Um processo pode 
25901 * ser suspenso porque deseja ler ou escrever em um pipe e não consegue ou 


25902 * porque deseja ler ou escrever a partir de um arquivo especial e não consegue. Quando um 
25903 * processo não consegue continuar, ele é suspenso e reanimado posteriormente, quando for 
25904 * capaz continuar. 

25905 + 

25906 * Os pontos de entrada para este arquivo são 

25907 * do pipe: executa a chamada de sistema PIPE 

25908 * pipe check: verifica se essa leitura ou escrita em um pipe é viável agora 

25909 * suspend: suspende processo que não consegue fazer leitura/escrita solicitada 
25910 * release: verifica se um processo suspenso pode ser liberado e faz 

25911 s isso 

25912 * revive: marca um processo suspenso como capaz de executar novamente 

25913 * do unpause: um sinal foi enviado para um processo; verifica se ele está suspenso 
25914 */ 

25915 


25916 #include "fs.h" 

25917 #include <fcntl.h> 

25918 #include <signal.h> 

25919 #include <minix/callnr.h> 

25920 #include <minix/com.h> 

25921 #include <sys/select.h> 

25922 #include <sys/time.h> 

25923 #include "file.h" 

25924 #include "fproc.h" 

25925 #include "inode.h" 

25926 #include "param.h" 

25927 #include "super.h" 

25928 #include "select.h" 

25929 

25930 /*======================== * 
25931 $ do_pipe * 
25932 * ===> * / 
25933 PUBLIC int do pipe 

25934 1 

25935 /* Executa a chamada de sistema pipe(fil des). */ 

25936 

25937 register struct fproc “rfp; 

25938 register struct inode “rip; 

25939 int r; 

25940 struct filp *fil ptrO, *fil ptrl; 


25941 int fil des[2]; /* a resposta fica aqui */ 
25942 
25943 /* Adquire dois descritores de arquivo. */ 


25944 rfp = fp; 

25945 if C (r = get fd(O, R BIT, &fil des[0], &fil ptr0)) != OK) return(r); 
25946 rfp->fp filplfil des[0]] = fil ptro; 

25947 fil ptrO0->filp count = 1; 

25948 if C Cr = get fd(O, W BIT, &fil des[1], &fil ptrl)d) != OK) 1 


25949 rfp->fp filp[fil des[0]] = NIL FILP; 
25950 fil ptrO->filp count = 0; 

25951 return(r); 

25952 


} 
25953 rfp->fp_filp[fil_des[1]] = fil_ptr1; 
25954 fil ptrl->filp count = 1; 
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25955 
25956 
25957 
25958 
25959 
25960 
25961 
25962 
25963 
25964 
25965 
25966 
25967 
25968 
25969 
25970 
25971 
25972 
25973 
25974 
25975 
25976 
25977 
25978 
25979 
25980 
25981 


25983 
25984 
25985 
25986 
25987 
25988 
25989 
25990 
25991 
25992 
25993 
25994 
25995 
25996 
25997 
25998 
25999 
26000 
26001 
26002 
26003 
26004 
26005 
26006 
26007 
26008 
26009 
26010 
26011 
26012 
26013 
26014 


/* Faz o i-node no dispositivo de pipe. */ 
if C Crip = alloc inode(lroot dev, I REGULAR) ) == NIL INODE) { 
rfp->fp filp[fil des[0]] = NIL FILP; 
fil ptrO->filp count = 0; 
rfp->fp filp[fil des[1]] = NIL FILP; 
fil ptrl->filp count = 0; 
return(err code); 


} 


if (read onlyCrip) != OK) 
panic(. FILE ,"pipe device is read only", NO NUM); 


rip->i pipe = I PIPE; 

rip->i mode &= “I REGULAR; 

rip->i mode |= I NAMED PIPE; /* pipes e FIFOs têm este bit ativo */ 
fil ptrO0->filp ino = rip; 

fil ptrO0->filp flags = O RDONLY; 

dup inode(rip); /* para utilização dupla */ 

fil ptrl->filpiino = rip; 

fil ptrl->filp flags = O WRONLY; 

rw inode(rip, WRITING); /* marca o i-node como alocado */ 
m out.reply il = fil desT0]; 

m out.reply i2 = fil des[1]; 

rip->i update = ATIME | CTIME | MTIME; 


return(OK); 
J 
/* === ¥ 
ii pipe check * 
anen / 
PUBLIC int pipe check(rip, rw flag, oflags, bytes, position, canwrite, notouch) 
register struct inode “rip; /* o i-node do pipe */ 
int rw flag; /* READING ou WRITING */ 
int oflags; /* flags ativados por open ou fcntl */ 
register int bytes; /* bytes a serem lidos ou escritos (todos os trechos) */ 
register off t position; /* posição de arquivo corrente */ 
int *canwrite; /* retorna: número de bytes que podemos escrever */ 
int notouch; /* apenas verifica */ 


{ 

/* Os pipes são um pouco diferentes. Se um processo lê de um pipe vazio para 
* o qual ainda existe um escritor, suspende o leitor. Se o pipe está vazio 
* e não há nenhum escritor, retorna 0 bytes. Se um processo está escrevendo em um 
* pipe e ninguém o está lendo, fornece um erro de pipe quebrado. 


*/ 


/* Se for leitura, verifica se o pipe está vazio. */ 
if (rw flag == READING) { 
if (position >= rip->i size) 1 
/* O processo está lendo de um pipe vazio. */ 
int r = 0; 
if Cfind filpCrip, W_BIT) != NIL_FILP) { 
/* Existe um escritor */ 
if Coflags & O NONBLOCK) { 
r = EAGAIN; 
} else { 
if (!notouch) 
suspend(XPIPE); /* bloqueia o leitor */ 
r = SUSPEND; 
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26015 
26016 
26017 
26018 
26019 
26020 
26021 
26022 
26023 
26024 
26025 
26026 
26027 
26028 
26029 
26030 
26031 
26032 
26033 
26034 
26035 
26036 
26037 
26038 
26039 
26040 
26041 
26042 
26043 
26044 
26045 
26046 
26047 
26048 
26049 
26050 
26051 
26052 
26053 
26054 
26055 
26056 
26057 
26058 
26059 
26060 
26061 
26062 
26063 
26064 
26065 
26066 
26067 
26068 


26070 
26071 
26072 
26073 
26074 


/* Se necessário, ativa escritores que estão em repouso. */ 
if (susp count > O & !notouch) 
release(rip, WRITE, susp count); 
} 
return(r); 
} 
} else { 
/* O processo está escrevendo em um pipe. */ 
if Cfind filpCrip, R BIT) == NIL FILP) £ 
/* Diz ao núcleo para que gere um sinal SIGPIPE. */ 
if (!notouch) 
sys kil1C(Cint)Cfp - fproc), SIGPIPE); 
return(EPIPE):; 
} 


if (position + bytes > PIPE_SIZE(rip->i_sp->s_block_size)) { 
if (Coflags & O NONBLOCK) 
&& bytes < PIPE SIZE(rip->i sp->s block size)) 
return (EAGAIN) ; 
else if ((Coflags & O NONBLOCK) 
&& bytes > PIPE SIZE(rip->i sp->s block size)) 1 
if C (*canwrite = (PIPE SIZECrip->i sp->s block size) 
- position)) > 0) { 
/* Faz escrita parcial. Precisa despertar o leitor */ 
if (!notouch) 
release(rip, READ, susp count); 
return(1); 
} else { 
return(EAGAIN) ; 
} 
} 
if (bytes > PIPE_SIZE(rip->i_sp->s_block_size)) { 
if ((*canwrite = PIPE_SIZE(rip->i_sp->s_block_size) 
- position) > 0) { 
/* Realiza uma escrita parcial. Precisa despertar o leitor, 
* pois nos suspenderemos em read write) 
K 
/ 
release(rip, READ, susp count); 
return(1); 
} 
} 
if C!notouch) 
suspend(XPIPE); /* pára o gravador -- pipe cheio */ 
return (SUSPEND); 
} 


/* Escrita em um pipe vazio. Procura leitor suspenso. */ 
if (position == 0 && !notouch) 
release(rip, READ, susp_count); 


} 
*canwrite = 0; 
return(1); 
} 
Amma ""ísçezççõçõçõõãçá 
hd suspend * 
EDDS====DD=D>=>>=>>>>>>=>=>=>>>=>>>>>>>=>=>=>>=>>>>>>=>>=>>=>>>>>>>>=>>=>>=>>>>=>>>=>=>=>===> * / 


PUBLIC void suspend(task) 
int task; /* por quem o proc está esperando? (PIPE = pipe) */ 
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26075 1 

26076 /* Adota medidas para suspender o processamento da chamada de sistema presente. 

26077 * Armazena tabela de processos os parâmetros a serem usados na retomada. 

26078 * (Na verdade, eles não são usados quando um processo está esperando por um dispositivo 
26079 * de E/S, mas são necessários para os pipes e não vale a pena fazer a distinção.) 

26080 * O pseudo-erro SUSPEND deve ser retornado após chamar suspendO. 

26081 7 

26082 

26083 if (task == XPIPE || task == XPOPEN) susp count++;/* número de procs suspensos no pipe*/ 


26084 fp->fp suspended = SUSPENDED; 

26085 fp->fp fd = m_in.fd << 8 | cal nr; 

26086 fp->fp task = -task; 

26087 if (task == XLOCK) 1 

26088 fp->fp buffer (char *) m in.namel; /* terceiro arg de fentiO */ 
26089 fp->fp nbytes = m in.request; /* segundo arg de fentiO */ 
26090 } else { 

26091 fp->fp_buffer = m_in.buffer; /* para leituras e escritas */ 
26092 fp->fp_nbytes = m_in.nbytes; 

26093 } 

26094 } 


26096  /*=======DDDDDDDDDD5DD=DD5DDD0255D>=DD=DD=D==2=D=2=>==>=D==2==2==>=>==>=========>==>=========== * 
26097 ii release # 
26098 oDDDs====================================================================== * / 
26099 PUBLIC void release(ip, call nr, count) 

26100 register struct inode “ip; /* i-node do pipe */ 

26101 int call nr; /* READ, WRITE, OPEN ou CREAT */ 

26102 int count; /* número max de processos a liberar */ 

26103 { 

26104 /* Verifica se algum processo está preso no pipe, cujo i-node está em "ip". 
26105 * Se houver um e ele estava tentando executar a chamada indicada por "call nr”, 
26106 * o libera. 

26107 */ 

26108 

26109 register struct fproc *rp; 

26110 struct filp *f; 

26111 

26112 /* Tentar executar a chamada também inclui SELECIONAR nela com essa 

26113 * operação. 

26114 */ 

26115 if (call nr == READ || call nr == WRITE) { 

26116 int op; 

26117 if (call nr == READ) 

26118 op = SEL RD; 

26119 else 

26120 op = SEL WR; 

26121 for(f = &filp[0]; f < &filpINR FILPS]; f++) { 

26122 if Cf->filp count < 1 || !Cf->filp pipe select ops & op) || 
26123 f->filp ino != ip) 

26124 continue; 

26125 select callback(f, op); 

26126 f->filp pipe select ops & “op; 

26127 

26128 } 

26129 

26130 /* Pesquisa a tabela de proc. */ 

26131 for (rp = &fproc[0]; rp < &fproc[NR_PROCS]; rp++) { 

26132 if Crp->fp suspended == SUSPENDED && 

26133 rp->fp_revived == NOT_REVIVING && 

26134 Crp->fp fd & BYTE) == call nr && 
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26135 rp->fp filplrp->fp fd>>8]->filp ino == ip) { 

26136 revive(Cint) (rp - fproc), 0); 

26137 susp count--; /* monitora quem está suspenso */ 

26138 if (--count == 0) return; 

26139 3 

26140 

26141 3 

26143 /*===DD=DD>D=DDDDDDDDDDDDDDDDDDDDDDDDD0D0DDDDDDDD0D0DDD>D>D>D>=2>=>=>==>=>=>=>==>* 
26144 revive * 
26145 f=oonoDDDDD==o=DDDDDD=onDDDDDDDoonDDDDDDoocoDDDDDococnDoDDDcoconnoDoDDonnnn=*/ 
26146 PUBLIC void revive(proc nr, returned) 

26147 int proc nr; /* processo a reanimar */ 

26148 int returned; /* se estiver preso na tarefa, quantos bytes lidos */ 
26149 1 

26150 /* Reanima um processo bloqueado anteriormente. Quando um processo fica preso no tty, 
26151 * essa é a maneira pela qual ele é finalmente liberado. 

26152 */ 

26153 

26154 register struct fproc “rfp; 

26155 register int task; 

26156 

26157 if (proc nr < 0 || proc nr >= NR PROCS) 

26158 panic(. FILE ,"revive err”, proc nr); 


26159 rfp = &fproc[proc nr]; 
26160 if Crfp->fp suspended == NOT SUSPENDED || rfp->fp revived == REVIVING)return; 
26161 


26162 /* O flag "reviving” só se aplica aos pipes. Os processos que estão esperando pelo TTY 
26163 * recebem uma mensagem imediatamente. O processo de reanimação é diferente para TTY e 
26164 * pipes. Para seleção e reanimação de TTY, o trabalho já está feito, para pipes, não: 
26165 * o proc precisa ser reiniciado para que possa tentar novamente. 

26166 */ 


26167 task = -rfp->fp_task; 
26168 if (task == XPIPE || task == XLOCK) { 


26169 /* Reanima um processo suspenso em um pipe ou bloqueado. */ 

26170 rfp->fp_revived = REVIVING; 

26171 reviving++; /* o processo estava esperando no pipe ou bloqueado */ 
26172 } else { 

26173 rfp->fp_suspended = NOT_SUSPENDED; 

26174 if (task == XPOPEN) /* processo bloqueado em open ou create */ 

26175 replyCproc nr, rfp->fp fd>>8); 

26176 else if (task == XSELECT) { 

26177 reply(proc nr, returned); 

26178 } else { 

26179 /* Reanima um processo suspenso no TTY ou em outro dispositivo. */ 
26180 rfp->fp_nbytes = returned; /* finge que quer apenas o que há */ 
26181 reply(proc_nr, returned); /* desbloqueia o processo */ 
26182 

26183 

26184 + 

26186  /*===================>====D>=>>"2=>D=D02=D=>>0=>D=>=2==D=>======2===>====>============= * 
26187 $ do_unpause * 
26188 $ psa y 
26189 PUBLIC int do unpause() 

26190 { 

26191 /* Um sinal foi enviado para um usuário que está parado no sistema de arquivos. 
26192 * Cancela a chamada de sistema com a mensagem de erro EINTR. 

26193 LA 


26194 
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26195 register struct fproc “rfp; 

26196 int proc nr, task, fild; 

26197 struct filp *f; 

26198 dev t dev; 

26199 message mess; 

26200 

26201 if (who > PM PROC NR) return(EPERM); 

26202 proc nr = m_in.pro; 

26203 if (proc nr < 0 || proc nr >= NR PROCS) 

26204 panic(. FILE ,"unpause err 1", proc nr); 
26205 rfp = &fproc[proc nr]; 

26206 if (rfp->fp suspended == NOT SUSPENDED) return(OK); 
26207 task = -rfp->fp task; 


26208 

26209 switch (task) 1 

26210 case XPIPE: /* processo tentando ler ou escrever um pipe */ 
26211 break; 

26212 

26213 case XLOCK: /* processo tentando configurar uma trava com FCNTL */ 
26214 break; 

26215 

26216 case XSELECT: /* processo bloqueando em select() */ 

26217 select forget(proc nr); 

26218 break; 

26219 

26220 case XPOPEN: /* processo tentando abrir uma fifo */ 

26221 break; 

26222 

26223 default: /* processo tentando E/S de dispositivo (ex., tty)*/ 
26224 fild = Crfp->fp fd >> 8) & BYTE;/* extrai descritor de arquivo */ 
26225 if Cfild< 0 || fild >= OPEN MAX) 

26226 panic(. FILE ,"unpause err 2",NO NUM); 

26227 f = rfp->fp filplfildl; 

26228 dev = (dev t) f->filp ino->i zone[0]; /* dispositivo aguardando */ 
26229 mess.TTY LINE = (dev >> MINOR) & BYTE; 

26230 mess.PROC NR = proc nr; 

26231 

26232 /* Informa R ou W ao núcleo. O modo é da chamada corrente e não de open. */ 
26233 mess.COUNT = (rfp->fp fd & BYTE) == READ ? R BIT : W BIT; 

26234 mess.m type = CANCEL; 

26235 fp = rfp; /* abuso - ctty io usa fp */ 

26236 (C*dmap[ (dev >> MAJOR) & BYTE] .dmap io) (task, &mess); 

26237 } 

26238 

26239 rfp->fp_suspended = NOT_SUSPENDED; 

26240 reply(proc_nr, EINTR); /* chamada interrompida por sinal */ 

26241 return(0K); 

26242 } 

260244 [/f========D=DDD=D=D=2==D=DDD=DD>=D=2DD=2DD=DD>D=D>>=D=2=D==2=>==D>>==>===>>==>===>=========>======== * 
26245 i select_request_pipe fe 
26246 FESSESDESDSSSS SS SOSESS SEE SS CSS ESSES SESDEC SSSSISES SD SS=SSSS === s ns) 


26247 PUBLIC int select request pipe(struct filp *f, int *ops, int block) 
26248 1 


26249 int orig ops, r = 0, err, canwrite; 

26250 orig ops = *ops; 

26251 if (C*ops & SEL RDJ) 1 

26252 if (Cerr = pipe check(f->filp ino, READING, O, 
26253 1, f->filp pos, &canwrite, 1)) != SUSPEND) 


26254 r |= SEL RD; 
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if (err < 0 && err != SUSPEND && (“ops & SEL ERR)) 
r |= SEL ERR; 
} 
if (C*ops & SEL_WR)) { 
if (Cerr = pipe_check(f->filp_ino, WRITING, O, 
1, f->filp_pos, &canwrite, 1)) != SUSPEND) 


r |= SEL_WR; 
if (err < 0 && err != SUSPEND && (*ops & SEL_ERR)) 
r |= SEL ERR; 
} 
*ops = rj 


if (lr && block) { 
f->filp pipe select ops |= orig ops; 


} 


return SEL OK; 


PUBLIC int select match pipe(struct filp *f) 


/* reconhece pipe ou pipe nomeado (FIFO) */ 

if (f & f->filp ino && (f->filp ino->i mode & I NAMED PIPE)) 
return 1; 

return 0; 
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26300 
26301 
26302 
26303 
26304 
26305 
26306 
26307 
26308 
26309 
26310 
26311 
26312 
26313 
26314 
26315 
26316 
26317 
26318 
26319 


/* Este arquivo contém as funções que pesquisam nomes de caminho no sistema 


* de diretório e determinam o número de i-node que acompanha determinado nome de caminho. 


* Os pontos de entrada para este arquivo são 


eat path: a rotina "principal” do mecanismo de conversão de caminho para i-node 
last dir: encontra o último diretório em um caminho dado 
* advance: analisa um componente de um nome de caminho 
* search dir: pesquisa um diretório em busca de uma string e retorna seu número de i-node 
*/ 
#include "fs.h" 
#include <string.h> 
#include <minix/callnr.h> 
#include "buf.h" 
#include "file.h" 
#include "fproc.h" 
#include "inode.h" 
#include "super.h" 


PUBLIC char dot1[2] = "."; /* usado por search_dir para ignorar as */ 


940 
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26320 
26321 
26322 
26323 
26324 
26325 
26326 
26327 
26328 
26329 
26330 
26331 
26332 
26333 
26334 
26335 
26336 
26337 
26338 
26339 
26340 
26341 
26342 
26343 
26344 
26345 
26346 
26347 
26348 
26349 


PUBLIC char dot2[3] = ".."; /* permissões de acesso para . e... */ 


FORWARD | PROTOTYPE( char *get name, (char *old name, char string [NAME MAX1) ); 


[/B============>==>==>=>>=>=>>=>=>=>>=>>=>>>=>>=>=>=>>>>>>=>>=>>>>>>>>>=>>=>>=>>>=>>=>====>===>"* 
* eat path * 
HDDOD=DDDDD0DDD>DDDDDD>>>D0D>DD>>"D0>>>>>>0=>=>>>>"0>>>>>>""=>>>>>>==>=>>>>====>>=>=>>* / 

PUBLIC struct inode *eat path(path) 

char *path; /* o nome de caminho a ser analisado */ 

{ 


/* Analisa o caminho "path" e coloca seu i-node na tabela de i-nodes. Se não for possível, 


* retorna NIL INODE como valor de função e um código de erro em "err code”. 


*/ 


register struct inode *ldip, *rip; 
char string[NAME_MAX]; /* contém 1 nome de componente de caminho aqui */ 


/* Primeiro abre o caminho até o último diretório. */ 
if C (ldip = last dirC(path, string)) == NIL INODE) { 
return(NIL INODE); /* não pudemos abrir o último diretório */ 


} 


/* O caminho consistindo apenas em "/" é um caso especial, verifica isso. */ 
if (string[0] == ’\0°) return(ldip); 


/* Obtém o último componente do caminho. */ 
rip = advance(ldip, string); 
put_inode(ldip); 

return(rip); 


} 

JA E a a a a 
* last dir * 
ae y; 

PUBLIC struct inode *last_dir(path, string) 

char *path; /* o nome de caminho a ser analisado */ 

char string[NAME MAX]; /* o último componente é retornado aqui */ 

{ 


/* Dado um caminho, 'path”, localizado no espaço de endereço do FS, analisa-o até 


* o último diretório, busca o i-node do último diretório na 

* tabela de i-nodes e retorna um ponteiro para o i-node. Além 
disso, retorna o último componente do caminho em “string”. 

* Se o último diretório não puder ser aberto, retorna NIL INODE e 
* o motivo da falha em "err code”. 


*/ 


register struct inode *rip; 
register char *new_name; 
register struct inode *new_ip; 


/* O caminho é absoluto ou relativo? Inicializa "rip" de acordo com isso. */ 
rip = (“path == '/" ? fp->fp rootdir : fp->fp workdir); 


/* Se o dir foi removido ou o caminho está vazio, retorna ENOENT. */ 
if Crip->i nlinks == 0 || “path == "10') { 

err code = ENOENT; 

return(NIL INODE); 
} 


dup_inode(rip); /* o i-node será retornado com put_inode */ 
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26380 
26381 
26382 
26383 
26384 
26385 
26386 
26387 
26388 
26389 
26390 
26391 
26392 
26393 
26394 
26395 
26396 
26397 
26398 
26399 
26400 
26401 
26402 
26403 
26404 
26405 
26406 
26407 
26408 


26410 
26411 
26412 
26413 
26414 
26415 
26416 
26417 
26418 
26419 
26420 
26421 
26422 
26423 
26424 
26425 
26426 
26427 
26428 
26429 
26430 
26431 
26432 
26433 
26434 
26435 
26436 
26437 
26438 
26439 


/* Percorre o caminho, componente por componente. */ 
while (TRUE) 1 
/* Extrai um componente. */ 
if (C (new name = get name(path, string)) == (char*) 0) { 
put inode(rip); /* caminho impróprio no espaço de usuário */ 
return(NIL INODE); 
} 
if (“new name == ’\0’°) { 
if C Crip->i_mode & I_TYPE) == I_DIRECTORY) { 


return(rip); /* saída normal */ 
} else { 
/* o último arquivo do prefixo do caminho não é um diretório */ 
put_inode(rip); 
err_code = ENOTDIR; 
return(NIL_INODE) ; 
} 


} 


/* Há mais caminho. Continua analisando. */ 

new_ip = advance(rip, string); 

put_inode(rip); /* rip obsoleto ou irrelevante */ 
if (new ip == NIL_INODE) return(NIL_INODE); 


/* A chamada para advance() foi bem-sucedida. Busca o próximo componente. */ 
path = new name; 
rip = new ip; 


} 

} 

J * === * 
* get name * 
o n a) 

PRIVATE char *get_name(old_name, string) 

char *old name; /* nome de caminho a analisar */ 

char string[NAME MAX]; /* componente extraído de "old name” */ 

{ 


/* Dado um ponteiro para um nome de caminho no espaço do FS, "old name”, copia o 
* próximo componente na "string” e preenche com zeros. É retornado um ponteiro para a 
* parte do nome ainda não analisada. A grosso modo, 

"get name” = "old name” - "string. 


* Esta rotina segue a convenção padrão de que /usr/ast, /usr//ast, 


* //usr///ast e /usr/ast/ são todos equivalentes. 


register int c; 
register char *np, *rnp; 


np = string; /* "np" aponta para a posição corrente */ 
rnp = old name; /* "rnp” aponta para a string não analisada */ 
while C (c = *rnp) == "/'D rnp++; /* pula barras iniciais */ 


/* Copia o caminho não analisado, "old name”, em, "string". */ 
while ( rnp < &old name[PATH MAX] && c I="/" & c != °\0’°) { 

if (np < &string[NAME_MAX]) *np++ = C; 

c = *++rnp; /* avança para o próximo caractere */ 


} 


/* Para tornar /usr/ast/ equivalente a /usr/ast, pula as barras finais. */ 
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26440 while (c == "/" && rnp < &old name[PATH MAXT) c = *++rnp; 

26441 

26442 if (np < &string[NAME MAXI) *np = “NO”; /* Termina a string */ 

26443 

26444 if (rnp >= &old name[PATH MAXI) 1 

26445 err code = ENAMETOOLONG; 

26446 return((char *) 0); 

26447 

26448 return(rnp); 

26449 + 

26451  /*====================== + 
26452 à k 
26453 

26454 PUBLIC struct inode *advance(dirp, string) 

26455 struct inode *dirp; /* i-node do diretório a ser pesquisado */ 
26456 char string[NAME MAX]; /* nome do componente a procurar */ 

26457 { 

26458 /* Dados um diretório e um componente de um caminho, pesquisa o componente no 
26459 * diretório, encontra o i-node, o abre e retorna um ponteiro para sua entrada de i-node. 
26460 * Se isso não puder ser feito, retorna NIL INODE. 

26461 */ 

26462 

26463 register struct inode “rip; 

26464 struct inode *rip2; 

26465 register struct super block *sp; 


26466 int r, inumb; 
26467 dev t mnt dev; 
26468 ino t numb; 


26469 

26470 /* Se “string” estiver vazia, gera o mesmo i-node imediatamente. */ 

26471 if (string[0] == 'N0') { return(get inode(dirp->i dev, (int) dirp->i num)); 3 
26472 


26473 /* Verifica NIL INODE. */ 
26474 if (dirp == NIL INODE) { return(NIL INODE); + 


26475 

26476 /* Se "string" não estiver presente no diretório, sinaliza erro. */ 

26477 if C (r = search dir(dirp, string, &numb, LOOK UP) != OK) 1 

26478 err code = r; 

26479 return(NIL INODE); 

26480 

26481 

26482 /* Não vai além do diretório-raiz corrente, a menos que a string seja dot2. */ 
26483 if (dirp == fp->fp rootdir && strcmp(string, "..") == 0 && string != dot2) 
26484 return(get inode(dirp->i dev, (int) dirp->i num)); 

26485 

26486 /* O componente foi encontrado no diretório. Obtém o i-node. */ 


26487 if C Crip = get inode(dirp->i dev, (int) numb)) == NIL INODE) 1 
26488 return(NIL INODE); 


26489 3 

26490 

26491 if Crip->i num == ROOT INODE) 

26492 if (dirp->i num == ROOT INODE) { 

26493 if Cstring[1] == "".') € 

26494 for (sp = &super block[1]; sp < &super block[NR SUPERS]; sp++){ 
26495 if (sp->s dev == rip->i dev) 1 

26496 /* Libera o i-node da raiz. Substitui pelo 
26497 * j-node montado. 

26498 */ 


26499 put inode(rip); 
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26500 
26501 
26502 
26503 
26504 
26505 
26506 
26507 
26508 
26509 
26510 
26511 
26512 
26513 
26514 
26515 
26516 
26517 
26518 
26519 
26520 
26521 
26522 
26523 
26524 
26525 
26526 
26527 
26528 
26529 
26530 


26532 
26533 
26534 
26535 
26536 
26537 
26538 
26539 
26540 
26541 
26542 
26543 
26544 
26545 
26546 
26547 
26548 
26549 
26550 
26551 
26552 
26553 
26554 
26555 
26556 
26557 
26558 
26559 


mnt dev = sp->s imount->i dev; 
inumb = (int) sp->s imount->i num; 
rip2 = get inode(mnt dev, inumb); 
rip = advance(rip2, string); 

put inode(rip2); 

break; 


} 
} 
if Crip == NIL_INODE) return(NIL INODE) ; 


/* Verifica se o i-node está montado. Se estiver, troca para o diretório-raiz do 
* sistema de arquivos montado. O super block fornece o vínculo entre o 
* j-node montado e o diretório-raiz do sistema de arquivos montado. 

*/ 
while (Crip != NIL INODE && rip->i_mount == I_MOUNT) { 
/* O i-node está realmente montado. */ 
for (sp = &super_block[0]; sp < &super_block[NR_SUPERS]; sp++) { 
if (sp->s_imount == rip) { 
/* Libera o i-node montado. Substitui pelo 
* i-node da raiz do dispositivo montado. 
*/ 
put_inode(rip); 
rip = get inode(sp->s dev, ROOT_INODE); 


break; 
} 
} 
} 
return(rip); /* retorna ponteiro para componente do i-node */ 

} 
A 

* search_dir * 

BODDDDDDD=DDDDDDDD>DDDD0>>>>D>=>>>>>>D0=>>>>>>0=>>>>>>02=>>>>>>"=>=>>>>"===>>>>>===>* / 
PUBLIC int search dir(ldir ptr, string, numb, flag) 

register struct inode *Tdir ptr; /* ptr para i-node do dir a pesquisar */ 
char string[NAME MAX]; /* componente a ser procurado */ 
ino t *numb; /* ponteiro para número de i-node */ 
int flag; /* LOOK UP, ENTER, DELETE ou IS EMPTY */ 

{ 
/* Esta função pesquisa o diretório cujo i-node é apontado por "Tdip': 

* if (flag == ENTER) insere "string' no diretório com número de i-node "*numb”; 

* if (flag == DELETE) exclui "string' do diretório; 

* if (flag == LOOK UP) procura "string" e retorna o número de i-node em "numb”; 


* if (flag == IS EMPTY) retorna OK apenas se . e .. estiverem no dir, senão, ENOTEMPTY; 


$ se "string' for dot1 ou dot2, nenhuma permissão de acesso será verificada. 


*/ 


register struct direct *dp = NULL; 
register struct buf *bp = NULL; 
inti C € hit, t, match; 

mode_t bits; 

off_t pos; 

unsigned new_slots, old_slots; 
block_t b; 

struct super_block *sp; 

int extended = 0; 
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26560 /* Se "Tdir ptr” não for um ponteiro para um i-node de dir, erro. */ 
26561 if C (ldir ptr->i mode & I TYPE) != I DIRECTORY) return(ENOTDIR); 
26562 

26563 r = 0K; 


26564 

26565 if (flag != IS_EMPTY) { 

26566 bits = (flag == LOOK_UP ? X_BIT : W_BIT | X_BIT); 

26567 

26568 if (string == dot1 || string == dot2) { 

26569 if (flag != LOOK UP) r = read_only(ldir_ptr); 

26570 /* apenas um dispositivo gravável é exigido. */ 
26571 } 

26572 else r = forbidden(ldir_ptr, bits); /* verifica as permissões de acesso */ 
26573 } 

26574 if (r != OK) return(r); 

26575 

26576 /* Percorre o diretório um bloco por vez. */ 


26577 old slots = (unsigned) (ldir_ptr->i_size/DIR_ENTRY_SIZE); 
26578 new_slots = 0; 
26579 e_hit = FALSE; 


26580 match = 0; /* configura quando ocorre uma correspondência de string */ 
26581 

26582 for (pos = 0; pos < ldir_ptr->i_size; pos += ldir_ptr->i_sp->s_block_size) { 

26583 b = read_map(ldir_ptr, pos); /* obtém número do bloco */ 

26584 

26585 /* Como os diretórios não têm lacunas, 'b” não pode ser NO BLOCK. */ 

26586 bp = get block(ldir ptr->i dev, b, NORMAL); /* obtém um bloco de diretório */ 
26587 

26588 if (bp == NO BLOCK) 

26589 panic(C. FILE ,"get block returned NO BLOCK", NO NUM); 

26590 

26591 /* Pesquisa um bloco de diretório. */ 

26592 for (dp = &bp->b dir[0]; 

26593 dp < &bp->b dir[NR DIR ENTRIES(Idir ptr->i sp->s block size)]; 

26594 dp++) 1 

26595 if (++new slots > old slots) { /* não foi encontrado, mas deixa espaço */ 
26596 if (flag == ENTER) e hit = TRUE; 

26597 break; 

26598 } 

26599 

26600 /* A correspondência ocorre se a string é encontrada. */ 

26601 if (flag != ENTER && dp->d_ino != 0) { 

26602 if (flag == IS_EMPTY) { 

26603 /* Se este teste é bem-sucedido, o dir não está vazio. */ 
26604 if (strcmp(dp->d_name, "." ) != 0 & 

26605 strcmp(dp->d_name, "..") != 0) match = 1; 

26606 } else { 

26607 if (strncmp(dp->d name, string, NAME MAX) == 0) { 

26608 match = 1; 

26609 } 

26610 } 

26611 ¥ 

26612 

26613 if (match) { 

26614 /* LOOK_UP ou DELETE encontrou o que queria. */ 

26615 r= 0K; 

26616 if (flag == IS_EMPTY) r = ENOTEMPTY; 

26617 else if (flag == DELETE) { 

26618 /* Salva d_ino para recuperação. */ 


26619 t = NAME_MAX - sizeof(ino_t); 
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*(Cino t *) &dp->d name[t]) = dp->d ino; 
dp->d ino = 0; /* apaga a entrada */ 
bp->b dirt = DIRTY; 
ldir ptr->i update |= CTIME | MTIME; 
ldir ptr->i dirt = DIRTY; 
} else { 
sp = ldir_ptr->i_sp; /* flag’ é LOOK UP */ 
*numb = conv4(sp->s native, (int) dp->d ino); 
} 
put_block(bp, DIRECTORY BLOCK); 
return(r); 


} 


/* Verifica a existência de entrada livre para proveito de ENTER. */ 
if (flag == ENTER && dp->d_ino == 0) { 

e_hit = TRUE; /* encontramos uma entrada livre */ 

break; 


} 


/* O bloco inteiro foi pesquisado ou ENTER tem uma entrada livre. */ 
if (e hit) break; /* e_hit configurado se ENTER pode ser executado agora */ 
put_block(bp, DIRECTORY_BLOCK); /* caso contrário, continua a pesquisar dir */ 


/* Agora, o diretório inteiro foi pesquisado. */ 
if (flag != ENTER) { 

return(flag == IS_EMPTY ? OK : ENOENT); 
} 


/* Esta chamada é para ENTER. Se nenhuma entrada livre foi encontrada até agora, tenta 
* estender o diretório. 


*/ 
if (e hit == FALSE) { /* o diretório está cheio e não resta espaço no último bloco */ 
new slots++; /* aumenta o tamanho do diretório por 1 entrada */ 
if (new slots == 0) return(EFBIG); /* tam. diretório limitado pelo nr. de entradas */ 
if C (bp = new block(ldir ptr, Idir ptr->i size)) == NIL BUF) 
return(err code); 
dp = &bp->b dir[0]; 
extended = 1; 
} 


/* agora ’bp’ aponta para um bloco de diretório com espaço. 'dp' aponta para a entrada. */ 
(void) memset(dp->d_name, 0, (size_t) NAME_MAX); /* limpa a entrada */ 
for Ci = 0; string[i] & i < NAME MAX; i++) dp->d_name[i] = string[i]; 
sp = ldir_ptr->i_sp; 
dp->d_ino = conv4(sp->s_native, (int) *numb); 
bp->b_dirt = DIRTY; 
put_block(bp, DIRECTORY BLOCK); 
ldir ptr->i update |= CTIME | MTIME; /* marca mtime para atualização posterior */ 
ldir ptr->i dirt = DIRTY; 
if (new slots > old slots) { 
ldir ptr->i size = (off t) new slots * DIR ENTRY SIZE; 
/* Envia a alteração para o disco, caso o diretório seja estendido. */ 
if (extended) rw inode(ldir ptr, WRITING); 


return(OK); 
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26700 
26701 
26702 
26703 
26704 
26705 
26706 
26707 
26708 
26709 
26710 
26711 
26712 
26713 
26714 
26715 
26716 
26717 
26718 
26719 
26720 
26721 
26722 
26723 
26724 
26725 
26726 
26727 
26728 
26729 
26730 
26731 
26732 
26733 
26734 
26735 
26736 
26737 
26738 
26739 
26740 
26741 
26742 
26743 
26744 
26745 
26746 
26747 
26748 
26749 
26750 
26751 
26752 
26753 
26754 


/* Este a 
* Os pon 


EA 


tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 
tinclude 


FORWARD _ 


PUBLIC in 
{ 


/* Execut 


registe 
struct 
dev_t d 
mode_t 
int rdi 
inte ry 


/* Some 
if (!su 


rquivo executa as chamadas de sistema MOUNT e UMOUNT. 


tos de entrada para este arquivo são 


do_mount: executa a chamada de sistema MOUNT 
do_umount: executa a chamada de sistema UMOUNT 


“Es h” 
<fcntl.h> 
<minix/com.h> 
<sys/stat.h> 
"buf.h" 
"file.h" 
"fproc.h" 
"inode.h" 
"param.h" 
"super.h" 


PROTOTYPE( dev t name to dev, (char *path) Jè 


t do mountO 
a a chamada de sistema mount(name, mfile, rd only). */ 


r struct inode “rip, *root ip; 
super block *xp, *sp; 

ev; 

bits; 


r, mdir; /* TRUE se o arquivo {root|mount} for um dir */ 


found; 


nte o superusuário pode executar MOUNT. */ 
per user) return(EPERM); 


/* Se "name” não é para um arquivo especial de bloco, retorna erro. */ 


if (fetch name(m in.namel, m in.namel length, M1) != OK) return(err code); 


if (C (dev = name to dev(user path)) == NO DEV) return(err code); 


/* Varre superblocks para testar montagem de disp. e achar uma entrada livre */ 


sp=NI 

found = 

for (xp 
1 
1 

} 

if (fou 


if (sp == NIL SUPER) return(ENFILE); /* nenhum superbloco disponível */ 


/* Abre 


L SUPER; 

FALSE; 

= &super block[0]; xp < &super block[NR SUPERS]; xp++) { 

f (xp->s dev == dev) found = TRUE; /* ele já está montado? */ 

f (xp->s dev == NO DEV) sp = xp; /* registra a entrada livre */ 
nd) return(EBUSY); /* já está montado */ 


o dispositivo em que o sistema de arquivos reside. */ 


if (dev open(dev, who, m in.rd only ? R BIT : (CR BIT|W BITD) != OK) 
return(EINVAL); 
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26755 
26756 
26757 
26758 
26759 
26760 
26761 
26762 
26763 
26764 
26765 
26766 
26767 
26768 
26769 
26770 
26771 
26772 
26773 
26774 
26775 
26776 
26777 
26778 
26779 
26780 
26781 
26782 
26783 
26784 
26785 
26786 
26787 
26788 
26789 
26790 
26791 
26792 
26793 
26794 
26795 
26796 
26797 
26798 
26799 
26800 
26801 
26802 
26803 
26804 
26805 
26806 
26807 
26808 
26809 
26810 
26811 
26812 
26813 
26814 


/* Faz a cache se esquecer dos blocos abertos no sistema de arquivos */ 
(void) do sync(D; 
invalidate(dev); 


/* Preenche o superbloco. */ 
sp->s dev = dev; /* read super() precisa saber qual disp */ 
r = read super(sp); 


/* Ele é reconhecido como um sistema de arquivos do Minix? */ 
if Cr I=0K) É 

dev close(dev); 

sp->s dev = NO DEV; 

return(r); 


} 


/* Agora, obtém o i-node do arquivo onde vai haver a montagem. */ 
if (fetch name(m in.name2, m_in.name2_length, MI) != OK) { 
dev close(dev); 
sp->s dev = NO DEV; 
return(err code); 
} 
if C Crip = eat_path(user_path)) == NIL_INODE) { 
dev_close(dev); 
sp->s_dev = NO_DEV; 
return(err_code); 


} 


/* Ele não pode estar ocupado. */ 
r= 0K; 
if Crip->i count > 1) r = EBUSY; 


/* Ele não pode ser especial. */ 
bits = rip->i_mode & I_TYPE; 
if (bits == I_BLOCK_SPECIAL || bits == I_CHAR_SPECIAL) r = ENOTDIR; 


/* Obtém o i-node da raiz do sistema de arquivos montado. */ 


root_ip = NIL_INODE; /* se '°r’ não for OK, certifica-se de que isso seja definido */ 
if (Cr ==0K) É 
if C (root ip = get inode(dev, ROOT INODE)) == NIL INODE) r = err code; 
} 
if (root ip != NIL_INODE && root_ip->i_mode == 0) { 
r = EINVAL; 
} 


/* Os tipos de arquivo de "rip" e "root ip' não podem entrar em conflito. */ 
if Cr == 0K) { 
mdir = (Crip->i mode & I TYPE) == I DIRECTORY); /* TRUE se for dir */ 
rdir = ((root ip->i mode & I TYPE) == I DIRECTORY); 
if CImdir && rdir) r = EISDIR; 


/* Se houver erro, retorna o superbloco e os dois i-nodes; libera os mapas. */ 
if Cr ts 0K) É 

put inode(Crip); 

put inode(lroot ip); 

(void) do sync); 

invalidate(dev); 

dev close(dev); 

sp->s dev = NO DEV; 

return(r); 
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26815 } 

26816 

26817 /* Nada mais pode dar errado. Realiza a montagem. */ 

26818 rip->i_mount = I_MOUNT; /* este bit diz que o i-node está montado */ 
26819 sp->s_imount = rip; 


26820 sp->s_isup = root_ip; 
26821 sp->s_rd_only = m_in.rd_only; 
26822 return(0K); 


26823 } 

26825 — /f=================>===>==>==>==>=>=>>=>==>=>=>=>>=>>=>=>=>==>=>=>>=>>>>=>=>>=>=>=>>=>====>=>===> * 
26826 x do_umount * 
26827 EDDS====DDD>=>>=>>>>>>=>=>>=>>=>>>>>>>=>=>=>>=>=>>>>=>=>>>>=>>>>>>>>>=>>=>>=>=>>=>==>=>=>=>===>"* / 
26828 PUBLIC int do umount() 

26829 1 


26830 /* Executa a chamada de sistema umount (name). */ 
26831 dev t dev; 


26832 

26833 /* Somente o superusuário pode executar UMOUNT. */ 

26834 if (!super user) return(EPERM) ; 

26835 

26836 /* Se "name” não for para um arquivo especial de bloco, retorna erro. */ 
26837 if (fetch name(m in.name, m in.name length, M3) != OK) return(err code); 
26838 if C (dev = name to dev(user path)) == NO DEV) return(err code); 

26839 

26840 return(unmount (dev)): 

26841 + 

26843 /*===D=DDDDDDDDDD52D5DD=DD5DD055D>=DD=DDDD==2=D2==2D>=D==D==2==>=>D==>==========="=========== * 
26844 ü unmount ii 
26845 PESE ae / 


26846 PUBLIC int unmount (dev) 
26847 Dev t dev; 


26848 1 

26849 /* Desmonta um sistema de arquivos pelo número do dispositivo. */ 

26850 register struct inode “rip; 

26851 struct super block *sp, *sp1; 

26852 int count; 

26853 

26854 /* Verifica se o dispositivo montado está ocupado. Somente 1 i-node que o está usando deve 
26855 * ser aberto - o i-node da raiz -- e esse i-node apenas 1 vez. 

26856 PÁ 


26857 count = 0; 
26858 for (rip = &inode[0]; rip< &inode[NR INODES]; rip++) 


26859 if Crip->i count > 0 && rip->i dev == dev) count += rip->i count; 
26860 if (count > 1) return(EBUSY); /* não pode desmontar um sistema de arquivos ocupado */ 
26861 


26862 /* Encontra o superbloco. */ 
26863 sp = NIL SUPER; 
26864 for (sp1 = &super block[0]; sp1 < &super block[NR SUPERS]; sp1++) 1 


26865 if (spl->s dev == dev) { 

26866 sp = spi; 

26867 break; 

26868 } 

26869 } 

26870 

26871 /* Sincroniza o disco e invalida a cache. */ 

26872 (void) do sync(D; /* retira da memória todos os blocos colocados na cache */ 
26873 invalidate(dev); /* invalida as entradas da cache para esse disp */ 


26874 if (sp == NIL SUPER) 1 
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return(EINVAL); 
} 


/* Fecha o dispositivo em que o sistema de arquivos reside. */ 
dev_close(dev); 


/* Conclui a desmontagem. */ 


sp->s imount->i mount = NO MOUNT; /* o i-node volta ao normal */ 
put inode(sp->s imount); /* libera o i-node montado */ 
put inode(sp->s isup); /* libera o i-node da raiz do FS montado */ 


sp->s imount = NIL INODE; 
sp->s dev = NO DEV; 


return(OK); 
} 
/* EEEE Y 
* name to dev * 
E E E E E E E e e TT */ 
PRIVATE dev t name to dev(path) 
char *path; /* ponteiro para nome de caminho */ 
{ 


/* Converte o arquivo especial de bloco "path” em um número de dispositivo. Se ’path’ 


não for um arquivo especial de bloco, retorna código de erro em "err code”. 


E 


register struct inode *rip; 
register dev t dev; 


/* Se "path" não pode ser aberto, abandona imediatamente. */ 
if C Crip = eat path(path)) == NIL INODE) return(NO DEV); 


/* Se "path" não é um arquivo especial de bloco, retorna erro. */ 
if C Crip->i mode & I TYPE) != I BLOCK SPECIAL) { 

err code = ENOTBLK; 

put inode(Crip); 

return(NO DEV); 
} 


/* Extrai o número do dispositivo. */ 
dev = (dev_t) rip->i_zone[0]; 
put_inode(rip); 

return(dev); 
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27000 
27001 
27002 
27003 
27004 
27005 
27006 
27007 
27008 
27009 


/* Este arquivo manipula as chamadas de sistema LINK e UNLINK. Ele também trata da liberação 


* do espaço de armazenamento usdo por um arquivo quando a última operação UNLINK é 


executada para um arquivo e os blocos devem ser retornados para o pool de blocos livres. 


Os pontos de entrada para este arquivo são 
do_link: executa a chamada de sistema LINK 
do_unlink: executa as chamadas de sistema UNLINK e RMDIR 
do_rename: executa a chamada de sistema RENAME 
truncate: libera todos os blocos associados a um i-node 
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27010 

27011 #include "fs.h” 

27012 &include <sys/stat.h> 
27013 include <string.h> 
27014 &include <minix/com.h> 
27015 &include <minix/callnr.h> 
27016 #include "buf.h” 

27017 #include "file.h" 
27018 #include "fproc.h" 
27019 &include "inode.h" 
27020 #include "param.h" 
27021 &include "super.h" 


27022 

27023 #define SAME 1000 

27024 

27025 FORWARD | PROTOTYPE( int remove dir, (struct inode *rldirp, struct inode *rip, 
27026 char dir name [NAME MAX]) ); 
27027 

27028 FORWARD PROTOTYPE( int unlink_file, (struct inode *dirp, struct inode *rip, 
27029 char file_name[NAME_MAX]) ; 
27030 

27031. /*====DD=DD=DD=DDDDDDDDDDDDDDDDDDDDDDDDD0D02DDDDDDDD0D02DDDDDDD>DD=D=>=>=>>=>=>===>* 
27032 E do link * 
27033 ÉS / 
27034 PUBLIC int do Tink(O) 

27035 { 

27036 /* Executa a chamada de sistema link(namel, name2). */ 

27037 

27038 register struct inode “ip, *rip; 

27039 register int r; 

27040 char string[NAME MAX]; 

27041 struct inode *new ip; 

27042 

27043 /* Verifica se 'name” (o arquivo a ser vinculado) existe. */ 

27044 if (fetch name(m in.namel, m in.namel length, M1) != OK) return(err code); 
27045 if C Crip = eat path(user path)) == NIL INODE) return(err code); 

27046 

27047 /* Verifica se o arquivo já tem o número máximo de vínculos. */ 

27048 r=0K; 

27049 if Crip->i nlinks >= (rip->i sp->s version == V1 ? CHAR MAX : SHRT MAX)) 
27050 r = EMLINK; 

27051 

27052 /* Somente superusuário pode criar vincular em diretórios. */ 

27053 if (r == 0K) 

27054 if C Crip->i mode & I TYPE) == I DIRECTORY && !super user) r = EPERM; 
27055 

27056 /* Se der erro com 'name”, retorna o i-node. */ 

27057 if Cr != 0K) { 

27058 put_inode(rip); 

27059 return(r); 

27060 } 

27061 

27062 /* O último diretório de ’name2’ existe? */ 

27063 if (fetch name(m in.name2, m in.name2 length, M1) != OK) 1 

27064 put inode(rip); 

27065 return(err code); 

27066 } 


27067 if C Cip = last_dir(user_path, string)) == NIL_INODE) r = err code; 
27068 
27069 /* Se "name2" existe (mesmo que não haja espaço), configura 


r’ como o erro. */ 
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27070 
27071 
27072 
27073 
27074 
27075 
27076 
27077 
27078 
27079 
27080 
27081 
27082 
27083 
27084 
27085 
27086 
27087 
27088 
27089 
27090 
27091 
27092 
27093 
27094 
27095 
27096 
27097 
27098 
27099 


27101 
27102 
27103 
27104 
27105 
27106 
27107 
27108 
27109 
27110 
27111 
27112 
27113 
27114 
27115 
27116 
27117 
27118 
27119 
27120 
27121 
27122 
27123 
27124 
27125 
27126 
27127 
27128 
27129 


if (r == 0K) É 
if (C (new ip = advance(ip, string)) == NIL INODE) { 
r = err code; 
if Cr == ENOENT) r = OK; 
} else { 
put_inode(new_ip); 
r = EEXIST; 


} 


/* Verifica a existência de vínculos entre dispositivos. */ 
if (r == 0K) 
if (Crip->i dev != ip->i_dev) r = EXDEV; 


/* Tenta vincular. */ 
if (r == 0K) 
r = search_dir(ip, string, &rip->i num, ENTER); 


/* Se tiver êxito, registra o vínculo. */ 
if (r == OK) 1 

rip->i_nlinks++; 

rip->i update |= CTIME; 

rip->i dirt = DIRTY; 
} 


/* Pronto. Libera os dois i-nodes. */ 
put_inode(rip); 
put_inode(ip); 


return(r); 

} 

JŽ ======= * 
3 do_unlink * 
À a e o ns JA 

PUBLIC int do_unlinkO 

{ 


/* Executa a chamada de sistema unlink(name) ou rmdir(name). O código das duas 
* é quase idêntico. Eles diferem apenas em alguns testes de condição. UnlinkO 
* pode ser usada pelo superusuário para fazer coisas perigosas; rmdir(), não. 


A 


register struct inode *rip; 
struct inode *rldirp; 

int rs 

char string[NAME MAX]; 


/* Obtém o último diretório no caminho. */ 
if (fetch name(m in.name, m in.name length, M3) != OK) return(err code); 
if C Crldirp = last dir(user path, string)) == NIL INODE) 

return(err code); 


/* O último diretório existe. O arquivo também existe? */ 
r = 0K; 
if C Crip = advance(rldirp, string)) == NIL INODE) r = err code; 


/* Se houver erro, retorna o i-node. */ 
if (r != 0K) É 

put_inode(rldirp); 

return(r); 
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27130 

27131 /* Não remove um ponto de montagem. */ 

27132 if Crip->i num == ROOT INODE) { 

27133 put inode(ridirp); 

27134 put inode(rip); 

27135 return(EBUSY); 

27136 

27137 

27138 /* Agora testa se a chamada é permitida, separadamente para unlinkO e rmdirO. */ 
27139 if (call nr == UNLINK) { 

27140 /* Somente superusuário pode desvincular (qualquer) diretório */ 

27141 if C Crip->i mode & I TYPE) == I DIRECTORY && !super user) r = EPERM; 

27142 

27143 /* Não desvincula um arquivo se for a raiz de um sistema de arquivos montado. */ 
27144 if Crip->i num == ROOT INODE) r = EBUSY; 

27145 

27146 /* Tenta realmente desvincular o arquivo; falha se o pai estiver no modo O etc. */ 
27147 if (r == OK) r = unlink fileCridirp, rip, string); 

27148 

27149 } else { 

27150 r = remove_dir(rldirp, rip, string); /* a chamada é RMDIR */ 

27151 } 

27152 

27153 /* Se a desvinculação foi possível, ela foi feita; caso contrário, não foi. */ 


27154 put_inode(rip); 
27155 put_inode(rldirp); 


27156 return(r); 

27157 3 

27159  [! isompmasim sejas ap q a 

27160 de do rename * 

27161 f=ooc=D=D=D====D>DDDD=000DD>DD00000DDDDD2D000DDDDDDD00nDDDDDcocnncoDooconnno=*/ 

27162 PUBLIC int do rename() 

27163 { 

27164 /* Executa a chamada de sistema rename(namel, name2). */ 

27165 

27166 struct inode *old dirp, *old ip; /* ptrs para i-nodes de dir e arquivo antigos */ 

27167 struct inode *new dirp, *new ip; /* ptrs para i-nodes de dir e arquivo novos */ 

27168 struct inode *new superdirp, *next new superdirp; 

27169 int r = OK; /* flag de erro; inicialmente nenhum erro */ 

27170 int odir, ndir; /* TRUE se o arquivo {old|new} for um dir */ 

27171 int same pdir; /* TRUE se os dirs pais forem os mesmos */ 

27172 char old name [NAME MAX], new name [NAME MAX]; 

27173 ino t numb; 

27174 int ri; 

27175 

27176 /* Verifica se 'namel' (o arquivo existente) existe. Obtém os i-nodes do dir e do 
arquivo. */ 

27177 if (fetch name(m in.namel, m in.namel length, M1) != OK) return(err code); 


27178 if C Cold dirp = last dir(user path, old name))==NIL INODE) return(err code); 
27179 

27180 if C Cold ip = advance(old dirp, old name)) == NIL INODE) r = err code; 

27181 


27182 /* Verifica se "'name2” (o novo nome) existe. Obtém os i-nodes do dir e do arquivo. */ 
27183 if (fetch name(m in.name2, m in.name2 length, M1) != OK) r = err code; 

27184 if (C (new dirp = last dir(user path, new name)) == NIL INODE) r = err code; 

27185 new ip = advance(new dirp, new name); /* não é obrigado a existir */ 

27186 

27187 if Cold ip != NIL INODE) 

27188 odir = (Cold ip->i mode & I TYPE) == I DIRECTORY); /* TRUE se for dir */ 


27189 
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27190 
27191 
27192 
27193 
27194 
27195 
27196 
27197 
27198 
27199 
27200 
27201 
27202 
27203 
27204 
27205 
27206 
27207 
27208 
27209 
27210 
27211 
27212 
27213 
27214 
27215 
27216 
27217 
27218 
27219 
27220 
27221 
27222 
27223 
27224 
27225 
27226 
27227 
27228 
27229 
27230 
27231 
27232 
27233 
27234 
27235 
27236 
27237 
27238 
27239 
27240 
27241 
27242 
27243 
27244 
27245 
27246 
27247 
27248 
27249 


/* Se estiver ok, verifica uma variedade de erros possíveis. */ 


i 


f Cr == 0K) { 
same_pdir = (old_dirp == new_dirp); 


/* O i-node antigo não deve ser um superdiretório do novo último dir. */ 
if Codir && !same_pdir) { 
dup_inode(new_superdirp = new_dirp); 


while (TRUE) { /* pode ficar preso em um laço FS */ 
if (new superdirp == old ip) { 
r = EINVAL; 
break; 
} 


next_new_superdirp = advance(new_superdirp, dot2); 
put_inode(new_superdirp); 
if (next new superdirp == new superdirp) 

break; /* volta para o diretório-raiz do sistema */ 
new superdirp = next new superdirp; 
if (new superdirp == NIL INODE) { 


/* Entrada ".." ausente. Presume o pior. */ 
r = EINVAL; 
break; 
} 
} 
put_inode(new_superdirp); 
} 
/* O nome antigo ou novo não deve ser . nem .. */ 
if (strcmp(old_name, ".")==0 || strcmp(old_name, "..")==0 || 


strcmp(new_name, ".")==0 || strcmp(new_name, "..")==0) r = EINVAL; 


/* Os dois diretórios pais devem estar no mesmo dispositivo. */ 
if Cold dirp->i dev != new dirp->i dev) r = EXDEV; 


/* Deve ser possível pesquisar e escrever nos diretórios pais */ 
if (Cr1 = forbiddenlold dirp, W BIT | X BIT)) != OK || 
Crl = forbidden(new dirp, W BIT | X BIT)D) != OK) r = r1; 


/* Alguns testes só se aplicam se o novo caminho existe. */ 
if (new ip == NIL INODE) 1 
/* não altera o nome de um arquivo com um FS montado nele. */ 
if Cold ip->i dev != old dirp->i dev) r = EXDEV; 
if Codir && new dirp->i nlinks >= 
(new dirp->i sp->s version == V1 ? CHAR MAX : SHRT MAX) && 
Isame pdir && r == OK) r = EMLINK; 


} else { 
if Cold ip == new ip) r = SAME; /* antigo=novo */ 
/* o arquivo antigo ou o arquivo novo tem um FS montado nele? */ 
if Cold ip->i dev != new ip->i dev) r = EXDEV; 
ndir = ((new ip->i mode & I TYPE) == I DIRECTORY); /* dir ? */ 
if (odir == TRUE && ndir == FALSE) r = ENOTDIR; 
if (odir == FALSE && ndir == TRUE) r = EISDIR; 

} 


* Se um processo tem outro diretório-raiz, além da raiz do sistema, poderíamos 
estar movendo "acidentalmente" seu diretório de trabalho para um lugar onde seu 
diretório-raiz não está mais em um superdiretório dele. Isso pode tornar a 
função chroot inútil. Se chroot vai ser usada freqüentemente, 
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27250 * provavelmente devemos verificar isso aqui. 

27251 */ 

27252 

27253 /* A alteração de nome provavelmente funcionará. Apenas duas coisas podem dar errado agora: 
27254 * 1. ser incapaz de remover o novo arquivo. (quando o novo arquivo já existe) 
27255 * 2. ser incapaz de fazer a nova entrada de diretório. (o novo arquivo não existe) 
27256 x [o diretório tem de crescer por um bloco e não pode, porque o disco 
27257 x está completamente cheio]. 

27258 ZA 

27259 if Cr == 0K) É 

27260 if (new ip != NIL INODE) 1 

27261 /* Já existe uma entrada para 'new'. Tenta removê-la. */ 

27262 if Codir) 

27263 r = remove dir(new dirp, new ip, new name); 

27264 else 

27265 r = unlink file(new dirp, new ip, new name); 

27266 

27267 /* se r estiver OK, a alteração de nome terá êxito, embora agora exista 
27268 * uma entrada não usada no novo diretório pai. 

27269 */ 

27270 

27271 

27272 if Cr == OK) É 

27273 /* Se o novo nome vai estar no mesmo diretório pai que o antigo, 

27274 * primeiro remove o nome antigo para liberar uma entrada para o novo nome; 
27275 * caso contrário, tenta primeiro criar a entrada do novo nome para garantir que 
27276 * a alteração de nome tenha êxito. 

27277 E / 

27278 numb = old ip->i num; /* número do i-node do arquivo antigo */ 
27279 

27280 if (same pdir) { 

27281 r = search dir(lold dirp, old name, Cino t *) O, DELETE); 

27282 /* não deve dar errado. */ 
27283 if (r==0K) (void) search dir(lold dirp, new name, &numb, ENTER); 
27284 } else { 

27285 r = search_dir(new_dirp, new_name, &numb, ENTER); 

27286 if Cr == 0K) 

27287 (void) search dir(old dirp, old name, (Cino t *) O, DELETE); 
27288 } 

27289 } 

27290 /* Se r estiver OK, ctime e mtime de old_dirp e de new_dirp foram marcados 
27291 * para atualização em search_dir. 

27292 */ 

27293 

27294 if (r == OK & odir && !same_pdir) { 

27295 /* Atualiza a entrada .. no diretório (ainda aponta para old_dirp). */ 
27296 numb = new_dirp->i_num; 

27297 (void) unlink_file(old_ip, NIL_INODE, dot2); 

27298 if (search_dir(old_ip, dot2, &numb, ENTER) == OK) { 

27299 /* Novo vínculo criado. */ 

27300 new_dirp->i_nlinks++; 

27301 new_dirp->i_dirt = DIRTY; 

27302 F 

27303 } 

27304 


27305 /* Libera os i-nodes. */ 
27306 put_inode(old_dirp); 
27307 put_inode(old_ip); 

27308 put_inode(new_dirp); 
27309 put_inode(new_ip); 
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27310 
27311 


27313 
27314 
27315 
27316 
27317 
27318 
27319 
27320 
27321 
27322 
27323 
27324 
27325 
27326 
27327 
27328 
27329 
27330 
27331 
27332 
27333 
27334 
27335 
27336 
27337 
27338 
27339 
27340 
27341 
27342 
27343 
27344 
27345 
27346 
27347 
27348 
27349 
27350 
27351 
27352 
27353 
27354 
27355 
27356 
27357 
27358 
27359 
27360 
27361 
27362 
27363 
27364 
27365 
27366 
27367 
27368 
27369 


return(r == SAME ? OK : r); 


} 
Jeo a aa 
* truncate 
iana a a a) 
PUBLIC void truncate(rip) 
register struct inode *rip; /* ponteiro para o i-node a ser truncado */ 


{ 


/* Remove todas as zonas a partir do i-node "rip' e marca como sujo. */ 


register block t b; 

zone t z, zone size, z1; 

off t position; 

int i, scale, file type, waspipe, single, nr indirects; 
struct buf *bp; 


dev t dev; 

file type = rip->i mode & I TYPE; /* verifica se o arquivo é especial 
if (file type == I CHAR SPECIAL || file type == I BLOCK SPECIAL) return; 
dev = rip->i dev; /* dispositivo no qual o i-node reside */ 


scale = rip->i sp->s log zone size; 
zone size = (zone t) rip->i sp->s block size < scale; 
nr indirects = rip->i nindirs; 


*/ 


/* Os pipes podem diminuir; portanto, ajusta tam. para garantir remoção de todas zonas. */ 


waspipe = rip->i pipe == I PIPE; /* TRUE esse era um pipe */ 
if (waspipe) rip->i size = PIPE SIZE(rip->i sp->s block size); 


/* Percorre o arquivo uma zona por vez, encontrando e liberando as zonas. 
for (position = 0; position < rip->i size; position += zone size) 1 
if C (b = read map(lrip, position)) != NO BLOCK) 1 
z = (zone t) b >> scale; 
free zone(dev, z); 


} 


3 


/* Todas as zonas de dados foram liberadas. Agora, libera as zonas indiretas. */ 


rip->i_dirt = DIRTY; 
if (waspipe) { 
wipe_inode(rip); /* limpa o i-node de pipes */ 


return; /* entradas indiretas contêm posições de arquivo */ 


} 

single = rip->i_ndzones; 

free_zone(dev, rip->i_zone[single]); /* zona indireta simples */ 
if C (z = rip->i_zone[single+1]) != NO ZONE) { 


/* Libera todas as zonas indiretas simples apontadas pela dupla. */ 


b = (block t) z << scale; 
bp = get block(dev, b, NORMAL); /* obtém zona indireta dupla */ 
for Ci = 0; i <nr indirects; i++) { 

zi = rd indir(bp, 1); 

free zone(dev, z1); 


} 


/* Agora, libera a própria zona indireta dupla. */ 
put_block(bp, INDIRECT BLOCK); 
free zone(dev, z); 


} 


/* Deixa os nrs. de zona para de(1), para recuperar o aquivo após uma op. 


unlink(2). */ 
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27370 


27372 
27373 
27374 
27375 
27376 
27377 
27378 
27379 
27380 
27381 
27382 
27383 
27384 
27385 
27386 
27387 
27388 
27389 
27390 
27391 
27392 
27393 
27394 
27395 
27396 
27397 
27398 
27399 
27400 
27401 
27402 
27403 
27404 
27405 
27406 
27407 
27408 
27409 
27410 


27412 
27413 
27414 
27415 
27416 
27417 
27418 
27419 
27420 
27421 
27422 
27423 
27424 
27425 
27426 
27427 
27428 
27429 


} 
[É === * 
i remove_dir ai 
Ke) 
PRIVATE int remove_dir(rldirp, rip, dir_name) 
struct inode *rldirp; /* diretório pai */ 
struct inode *rip; /* diretório a ser removido */ 
char dir_name[NAME_MAX]; /* nome do diretório a ser removido */ 
{ 
/* Um arquivo de diretório tem de ser removido. Cinco condições precisam ser satisfeitas: 
i - O arquivo deve ser um diretório 
* - O diretório deve estar vazio (exceto quanto a . e...) 
x - O último componente do caminho não deve ser . nem .. 
i - O diretório não deve ser a raiz de um sistema de arquivos montado 
* - O diretório não deve ser o diretório raiz/de trabalho de ninguém 
*/ 
int r; 
register struct fproc *rfp; 
/* search dir verifica se rip também é um diretório. */ 
if (Cr = search dirClrip, "", Cino t *) O, IS EMPTY)) != OK) return r; 
if (strcmp(dir name, ".") == 0 || strcmp(dir name, "..") == 0)returnCEINVAL); 
if Crip->i num == ROOT INODE) return(EBUSY); /* não pode remover "root" */ 
for (rfp = &fproc[INIT PROC NR + 1]; rfp < &fproc[NR PROCS]; rfp++) 
if Crfp->fp workdir == rip || rfp->fp rootdir == rip) return(EBUSY); 
/* não pode remover o dir de trabalho de ninguém */ 
/* Tenta realmente desvincular o arquivo; falha se o pai estiver no modo O etc. */ 
if (Cr = unlink fileCridirp, rip, dir name)) != OK) return r; 
/* Desvincula . e .. do dir. O superusuário pode vincular e desvincular qualquer dir; 
* portanto, não faz suposições demais a respeito deles. 
*/ 
(void) unlink fileCrip, NIL INODE, dot1); 
(void) unlink fileCrip, NIL INODE, dot2); 
return(OK); 
} 
$ unlink_file i 
E / 
PRIVATE int unlink_file(dirp, rip, file_name) 
struct inode *dirp; /* diretório pai do arquivo */ 
struct inode *rip; /* i-node do arquivo, também pode ser NIL_INODE. */ 
char file_name[NAME_MAX]; /* nome do arquivo a ser removido */ 
{ 
/* Desvincula "file name"; rip deve ser o i-node de'file name” ou NIL INODE. */ 
ino t numb; /* número do i-node */ 
int r; 


/* Se rip não é NIL INODE, ele é usado para obter acesso mais rápido ao i-node. */ 
if Crip == NIL INODE) 1 

/* Procura arquivo no diretório e tenta obter seu i-node. */ 

err code = search dir(dirp, file name, &numb, LOOK UP); 

if (err code == OK) rip = get inode(dirp->i dev, (int) numb); 
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27430 
27431 
27432 
27433 
27434 
27435 
27436 
27437 
27438 
27439 
27440 
27441 
27442 
27443 
27444 
27445 


if (err code != OK || rip == NIL INODE) return(err code); 
} else { 
dup_inode(rip); /* o i-node será retornado com put_inode */ 


} 
r = search dir(dirp, file name, (ino_t *) O, DELETE); 


if (r == OK) { 
rip->i_nlinks--; /* entrada excluída do dir do pai */ 
rip->i update |= CTIME; 
rip->i dirt = DIRTY; 

} 


put_inode(rip); 
return(r); 
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27500 
27501 
27502 
27503 
27504 
27505 
27506 
27507 
27508 
27509 
27510 
27511 
27512 
27513 
27514 
27515 
27516 
27517 
27518 
27519 
27520 
27521 
27522 
27523 
27524 
27525 
27526 
27527 
27528 
27529 
27530 
27531 
27532 
27533 
27534 


/* Este arquivo contém o código para executar quatro chamadas de sistema relacionadas 


* a status e diretórios. 

* Os pontos de entrada para este arquivo são 

* do chdir: executa a chamada de sistema CHDIR 

* do chroot: executa a chamada de sistema CHROOT 
* do stat: executa a chamada de sistema STAT 

* do fstat: executa a chamada de sistema FSTAT 


do fstatfs: executa a chamada de sistema FSTATFS 


tinclude "fs.h" 
tinclude <sys/stat.h> 
tinclude <sys/statfs.h> 
tinclude <minix/com.h> 
tinclude "file.h" 
tinclude "fproc.h" 
tinclude "inode.h" 
ginclude "param.h" 
ginclude "super.h" 


FORWARD | PROTOTYPE( int change, (struct inode **iip, char *name ptr, int len)); 

FORWARD | PROTOTYPE( int change into, (struct inode **iip, struct inode *ip)); 

FORWARD | PROTOTYPE( int stat inode, (struct inode *rip, struct filp “fil ptr, 
char “user addr) : 


À E E TT Tr À / 
PUBLIC int do fchdir (O 
{ 

/* Muda o diretório em um fd já aberto. */ 

struct filp *rfilp; 


/* O descritor de arquivo é válido? */ 
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27535 if C Crfilp = get filp(m in.fd)) == NIL FILP) return(err code); 

27536 return change into(&fp->fp workdir, rfilp->filp ino); 

27537 + 

27539  /f=================>===D=D>===D=D=D===DD==2=>D=>===="===="=="============================= * 
27540 é do chdir * 
27541 0 fooonoDDD=D=ooDDDDDDD=onDDDDDDooooDDDDDoDocoDDDDDococnDoDDDcocnncoDoDooonno=*/ 
27542 PUBLIC int do chdir(QO) 

27543 { 

27544 /* Muda de diretório. Esta função também é chamada pelo MM para simular uma função 
27545 * chdir para executar uma operação EXEC etc. Ela também altera o diretório-raiz, os uids e 
27546 * gids, e umask. 

27547 xy 

27548 

27549 int r; 

27550 register struct fproc *rfp; 

27551 

27552 if (who == PM_PROC_NR) { 

27553 rfp = &fproc[m_in.slot1]; 

27554 put_inode(fp->fp_rootdir); 

27555 dup_inode(fp->fp_rootdir = rfp->fp_rootdir); 

27556 put_inode(fp->fp_workdir); 

27557 dup inode(fp->fp workdir = rfp->fp workdir); 

27558 

27559 /* O MM usa access() para verificar permissões. Para fazer isso funcionar, finge 
27560 * que as ids reais do usuário são iguais às suas ids efetivas. 

27561 * As chamadas do FS que não são access() não utilizam as ids reais, de modo que não 
27562 * são afetadas. 

27563 TA 

27564 fp->fp realuid = 

27565 fp->fp effuid = rfp->fp effuid; 

27566 fp->fp realgid = 

27567 fp->fp effgid = rfp->fp effgid; 

27568 fp->fp umask = rfp->fp umask; 

27569 return(OK); 

27570 } 

27571 

27572 /* Executa a chamada de sistema chdir(name). */ 

27573 r = change(&fp->fp workdir, m in.name, m in.name length); 

27574 return(r); 

27575 3 

27577 [Jf========>===>=>=""=D"======" ===> ==>==>"["="" ==" =>"====>=="00 000202 nscss= === === =—"* 
27578 Ed do chroot * 
27579 FoDE======D= ===>>> =5==">=="==="5=""25>2"="=>2D>=D0=="=""=="=0==2====="==="==>===="* / 
27580 PUBLIC int do chroot() 

27581 { 

27582 /* Executa a chamada de sistema chroot(name). */ 

27583 

27584 register int r; 

27585 

27586 if (!super user) return(EPERM) ; /* somente o su pode executar chroot() */ 
27587 r = change(&fp->fp rootdir, m in.name, m in.name length); 

27588 return(r); 


27589 3 
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27591 
27592 
27593 
27594 
27595 
27596 
27597 
27598 
27599 
27600 
27601 
27602 
27603 
27604 
27605 
27606 


27608 
27609 
27610 
27611 
27612 
27613 
27614 
27615 
27616 
27617 
27618 
27619 
27620 
27621 
27622 
27623 
27624 
27625 
27626 
27627 
27628 
27629 
27630 
27631 
27632 
27633 


27635 
27636 
27637 
27638 
27639 
27640 
27641 
27642 
27643 
27644 
27645 
27646 
27647 
27648 
27649 
27650 


[/B============>==>===>==>>=>>=>=>=>>=>>>>>=>=>=>=>>>>=>>=>>=>>>>>>>>=>>=>>=>>>>=>>=>=>=>=>=>===> * 
$ change * 
Kee a / 
PRIVATE int change(iip, name_ptr, len) 
struct inode **iip; /* ponteiro para o ponteiro de i-node do dir */ 
char *name_ptr; /* ponteiro para o nome de diretório para o qual mudar */ 
int len; /* comprimento da string do nome de diretório */ 


{ 
/* Executa o trabalho real de chdir e chrootO. */ 
struct inode “rip; 


/* Tenta abrir o novo diretório. */ 

if (fetch_name(name_ptr, len, M3) != OK) return(err_code); 

if C Crip = eat_path(user_path)) == NIL_INODE) return(err_code); 
return change into(iip, rip); 


PRIVATE int change into(iip, rip) 


struct inode **iip; /* ponteiro para o ponteiro de i-node do dir */ 
struct inode *rip; /* é nisso que o i-node precisa se transformar */ 
{ 


register int r; 


/* Ele deve ser um diretório e também poder ser pesquisado. */ 
if C Crip->i_mode & I_TYPE) != I DIRECTORY) 
r = ENOTDIR; 


else 


r forbidden(rip, X BIT); /* verifica se o dir pode ser pesquisado */ 
/* Se houver erro, retorna o i-node. */ 
if (Cr I=0K) É 

put inode(rip); 

return(r); 


} 
/* Tudo está OK. Faz a mudança. */ 
put_inode(*iip); /* libera o diretório antigo */ 
*iip = rip; /* adquire o novo */ 
return(0K); 
} 
A 
* do stat $ 


PUBLIC int do stat() 
{ 


/* Executa a chamada de sistema stat(name, buf). */ 


register struct inode *rip; 
register int r; 


/* Tanto stat() como fstat() usam a mesma rotina para fazer o trabalho real. Essa 
* rotina espera um i-node, de modo que o adquire temporariamente. 

*/ 

if (fetch_name(m_in.name1, m_in.namel_length, M1) != OK) return(err_code); 

if C Crip = eat_path(user_path)) == NIL_INODE) return(err_code); 

r = stat_inode(rip, NIL_FILP, m_in.name2); /* realmente executa o trabalho. */ 
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27651 
27652 
27653 


27655 
27656 
27657 
27658 
27659 
27660 
27661 
27662 
27663 
27664 
27665 
27666 
27667 
27668 


27670 
27671 
27672 
27673 
27674 
27675 
27676 
27677 
27678 
27679 
27680 
27681 
27682 
27683 
27684 
27685 
27686 
27687 
27688 
27689 
27690 
27691 
27692 
27693 
27694 
27695 
27696 
27697 
27698 
27699 
27700 
27701 
27702 
27703 
27704 
27705 
27706 
27707 
27708 
27709 
27710 


put inode(rip); /* libera o i-node */ 
return(r); 

} 

/* === ¥ 
* do fstat * 
BODDDDDDDDDDDDDDD>>D>>D>D0=>>D>>>>==>>>>>"0=>>>>>"=>>>>>>0=>>>>>">==>>>>>"=>=>>>>=0=* / 

PUBLIC int do fstat() 


{ 
/* Executa a chamada de sistema fstat(fd, buf). */ 


register struct filp *rfilp; 


/* O descritor de arquivo é válido? */ 
if C Crfilp = get_filp(m_in.fd)) == NIL FILP) return(err_code); 


return(stat_inode(rfilp->filp_ino, rfilp, m_in.buffer)); 


stat_inode 


Ei EEE E EEE. 7 
PRIVATE int stat_inode(rip, fil_ptr, user_addr) 
register struct inode *rip; /* ponteiro para i-node para stat */ 
struct filp *fil ptr; /* ponteiro de filp, fornecido por'fstat” */ 
char “user addr; /* endereço do espaço do usuário onde fica o buf de stat * 
{ 


/* Código comum para as chamadas de sistema stat e fstat. */ 


struct stat statbuf; 
mode_t mo; 
tnt- ry Si 


/* Atualiza os campos atime, ctime e mtime no i-node, se for necessário. */ 
if (Crip->i update) update_times(rip); 


/* Preenche a estrutura statbuf. */ 
mo = rip->i_mode & I_TYPE; 


/* true se for especial */ 
s = (mo == I_CHAR_SPECIAL || mo == I_BLOCK_SPECIAL); 


statbuf.st_dev = rip->i_dev; 

statbuf.st_ino = rip->i_num; 

statbuf.st_mode = rip->i_mode; 

statbuf.st_nlink = rip->i_nlinks; 

statbuf.st_uid = rip->i_uid; 

statbuf.st_gid = rip->i_gid; 

statbuf.st_rdev = (dev_t) (s ? rip->i_zone[0] : NO_DEV); 
statbuf.st_size = rip->i_size; 


if Crip->i pipe == I_PIPE) { 
statbuf.st_mode &= “TI REGULAR; /* zera o bit I REGULAR para pipes */ 
if (fil ptr != NIL FILP && fil ptr->filp mode & R BIT) 
statbuf.st size -= fil ptr->filp pos; 
} 


statbuf.st_atime = rip->i_atime; 
statbuf.st_mtime = rip->i_mtime; 
statbuf.st_ctime = rip->i_ctime; 


APÊNDICE B e O CóDiGo-FONTE DO MINIX 


961 


27711 
27712 
27713 
27714 
27715 
27716 


27718 
27719 
27720 
27721 
27722 
27723 
27724 
27725 
27726 
27727 
27728 
27729 
27730 
27731 
27732 
27733 
27734 
27735 
27736 
27737 


/* Copia a estrutura no espaço de usuário. */ 
r = sys datacopy(FS PROC NR, (vir bytes) &statbuf, 

who, (vir bytes) user addr, (phys bytes) sizeof(statbuf)); 
return(r); 

} 

/* === ¥ 
* do fstatfs * 
ODDS ====D=D>=>>=>>>>=>=>=>=>>=>>=>>>>=>>>=>>=>>=>=>>>>>=>>=>>=>>>>>>>=>=>>=>>=>>=>>=>>=>=>==>===> * / 

PUBLIC int do fstatfsQO 


{ 


/* Executa a chamada de sistema fstatfs(fd, buf). */ 


Struct 


statfs st; 


register struct filp *rfilp; 


int r; 


/* O descritor de arquivo é válido? */ 
if C Crfilp = get_filp(m_in.fd)) == NIL FILP) return(err_code); 


st.f_bsize = rfilp->filp_ino->i_sp->s_block_size; 


r = sys_datacopy(FS_PROC_NR, (vir_bytes) &st, 


who, (vir bytes) m_in.buffer, (phys_bytes) sizeof(st)); 


return(r); 


HEHEHEHEH AARAAAARRAAAARAR+ ++ 


servers/fs/protect.c 


HHHHHHHHH HHHH HHHH H+ HHHH H+H HH HH HHH H+H HHHH HHHH HHHH H+H HHHH HHHH H+ HH+HH+H+HH+H+H+H+H+H+ 


27800 
27801 
27802 
27803 
27804 
27805 
27806 
27807 
27808 
27809 
27810 
27811 
27812 
27813 
27814 
27815 
27816 
27817 
27818 
27819 
27820 


/* Este arquivo trata da proteção no sistema de arquivos. Ele contém o código 
* de quatro chamadas de sistema relacionadas à proteção. 


* Os pontos de entrada para este arquivo são 
* do chmod: executa a chamada de sistema CHMOD 


do chown: executa a chamada de sistema CHOWN 


do umask: executa a chamada de sistema UMASK 
* do access: executa a chamada de sistema ACCESS 
* forbidden: verifica se determinado acesso é permitido em determinado i-node 


*/ 


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


"fs.h" 
<unistd.h> 
<minix/callnr.h> 
"buf.h" 

"file.h" 
"fproc.h" 
"inode.h" 
"param.h" 
"super.h" 
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27821 
27822 
27823 
27824 
27825 
27826 
27827 
27828 
27829 
27830 
27831 
27832 
27833 
27834 
27835 
27836 
27837 
27838 
27839 
27840 
27841 
27842 
27843 
27844 
27845 
27846 
27847 
27848 
27849 
27850 
27851 
27852 
27853 
27854 
27855 
27856 
27857 


27859 
27860 
27861 
27862 
27863 
27864 
27865 
27866 
27867 
27868 
27869 
27870 
27871 
27872 
27873 
27874 
27875 
27876 
27877 
27878 
27879 
27880 


PUBLIC int do chmod() 
{ 


/* Executa a chamada de sistema chmod(name, mode). */ 


register struct inode *rip; 
register int r; 


/* Abre o arquivo temporariamente. */ 
if (fetch name(m in.name, m_in.name_length, M3) != OK) return(err_code); 
if C Crip = eat path(user path)) == NIL INODE) return(err code); 


/* Somente o proprietário ou o superusuário podem alterar o modo de um arquivo. 
* Ninguém pode alterar o modo de um arquivo em um FS somente para leitura. 
“7 
if Crip->i uid != fp->fp effuid && !super user) 
r = EPERM; 
else 
r = read onlyCrip); 


/* Se houve erro, retorna o i-node. */ 
if (r != OK) { 

put_inode(rip); 

return(r); 


} 


/* Faz alteração. Zera setgid se arquivo não pertence ao grupo do processo chamador * 


rip->i_mode = (rip->i_mode & “ALL MODES) | (m_in.mode & ALL_MODES) ; 

if (!super user && rip->i_gid != fp->fp_effgid)rip->i_mode &= “I SET GID BIT; 
rip->i update |= CTIME; 

rip->i dirt = DIRTY; 


put inode(Crip); 


return(OK); 

} 

/* === ¥ 
* do chown * 
EDDS====DDD>=>>=D>=>>=>=>>=>=>=>>=>>>>>>>=>>=>>=>=>>>>>=>>=>>=>>>>>>>>=>>>>=>>=>>=>>=>=>=>=>===> * / 

PUBLIC int do chown() 

{ 


/* Executa a chamada de sistema chown(name, owner, group). */ 


register struct inode *rip; 
register int r; 


/* Abre o arquivo temporariamente. */ 
if (fetch_name(m_in.name1, m_in.namel_length, M1) != OK) return(err_code); 
if C Crip = eat_path(user_path)) == NIL INODE) return(err_code); 


/* Não é permitido mudar o proprietário de um arquivo em um FS somente para leitura. * 


r = read_only(rip); 
if (Cr ==0K) { 
/* O FS é R/W. Se a chamada é permitida depende da posse etc. */ 
if (super user) { 
/* O superusuário pode fazer qualquer coisa. */ 
rip->i uid = m in.owner; /* outros, depois */ 
+ else { 
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27881 
27882 
27883 
27884 
27885 
27886 
27887 
27888 
27889 
27890 
27891 
27892 
27893 
27894 
27895 
27896 


27898 
27899 
27900 
27901 
27902 
27903 
27904 
27905 
27906 
27907 
27908 
27909 


27911 
27912 
27913 
27914 
27915 
27916 
27917 
27918 
27919 
27920 
27921 
27922 
27923 
27924 
27925 
27926 
27927 
27928 
27929 
27930 
27931 
27932 
27933 


27935 
27936 
27937 
27938 
27939 
27940 


/* Os usuários normais só podem alterar grupos de seus próprios arquivos. */ 
if Crip->i uid != fp->fp effuid) r = EPERM; 


n.owner) r = EPERM; /* não se desfaz de nada */ 


if Cfp->fp effgid != m in.group) r = EPERM; 


if Crip->i uid != m_i 

} 

} 

if (r == 0K) { 
rip->i_gid = m_in.group; 
rip->i mode &= “(I SET UID BIT | I SET GID BIT); 
rip->i update |= CTIME; 
rip->i dirt = DIRTY; 

} 

put_inode(rip); 

return(r); 

} 


PUBLIC int do umask() 

{ 

/* Executa a chamada de sistema umask 
register mode_t r; 


(co mode). */ 


r="fp->fp umask; /* configura "r 
fp->fp umask = “(m in.co mode & RWX MODES) ; 
return(r); /* retorna o complemento da máscara antiga */ 
} 
JŽ ======== * 
* do access 


PUBLIC int do access() 
{ 


/* Executa a chamada de sistema access(name, mode). */ 


struct inode *rip; 
register int r; 


/* Primeiro verifica se o modo está 


correto. */ 


if C (m _in.mode & “(CR OK | WOK | X_OK)) != 0 & m_in.mode != F OK) 


return(EINVAL) ; 


/* Abre temporariamente o arquivo cujo acesso deve ser verificado. */ 
if (fetch_name(m_in.name, m_in.name_length, M3) != OK) return(err_code); 


if (C Crip = eat_path(user_path)) == 


/* Agora verifica as permissões. */ 


NIL_INODE) return(err_code); 


r = forbidden(rip, (mode_t) m_in.mode); 


put_inode(rip); 
return(r); 


PUBLIC int forbidden(register struct inode *rip, mode_t access desired) 


{ 


/* Dados um ponteiro para um i-node, 


"rip", e o acesso desejado, determina 


com o complemento da máscara antiga */ 


964 SISTEMAS OPERACIONAIS 


27941 * se o acesso é permitido e, se não, por que não. A rotina pesquisa o 
27942 * uid do processo que fez a chamada na tabela 'fproc'. Se o acesso for permitido, OK 
27943 * será retornado; se for proibido, EACCES será retornado. 

27944 */ 

27945 

27946 register struct inode *old_rip = rip; 

27947 register struct super_block *sp; 

27948 register mode_t bits, perm_bits; 

27949 int r, shift, test_uid, test_gid, type; 

27950 

27951 if (Crip->i_mount == I MOUNT) /* o i-node está montado. */ 

27952 for (sp = &super block[1]; sp < &super block[NR SUPERS]; sp++) 
27953 if (sp->s imount == rip) 1 

27954 rip = get inode(sp->s dev, ROOT INODE) ; 

27955 break; 

27956 F/A 

27957 

27958 /* Isola os bits rwx relevantes do modo. */ 


27959 bits = rip->i mode; 

27960 test uid = (call nr == ACCESS ? fp->fp realuid : fp->fp effuid); 
27961 test gid = (call nr == ACCESS ? fp->fp realgid : fp->fp effgid); 
27962 if (test uid == SU UID) { 


27963 /* Concede permissão de leitura e escrita. Concede permissão de pesquisa para 
27964 * diretórios. Concede permissão de execução (para o que não for diretório) se 
27965 * e somente se um dosbits °X’ estiver ativo. 

27966 TÁ 

27967 if C (bits &I TYPE) == I DIRECTORY || 

27968 bits & ((X BIT << 6) | (X BIT << 3) | X BIT)) 

27969 perm bits = R BIT | W BIT | X BIT; 

27970 else 

27971 perm bits = R BIT | W BIT; 

27972 } else { 

27973 if (test uid == rip->i_uid) shift = 6; /* proprietário */ 

27974 else if (test gid == rip->i_gid ) shift = 3; /* grupo */ 

27975 else shift = 0; /* outros */ 

27976 perm_bits = (bits >> shift) & (R BIT | W BIT | X_BIT); 

27977 } 

27978 

27979 /* Se o acesso desejado não for um subconjunto do que é permitido, ele será recusado. */ 


27980 r= 0; 
27981 if ((perm bits | access desired) != perm bits) r = EACCES; 


27982 

27983 /* Verifica se alguém está tentando escrever em um sistema de arquivos montado 
27984 * somente para leitura. 

27985 */ 


27986 type = rip->i mode & I TYPE; 

27987 if (r == 0K) 

27988 if (access desired & W BIT) 
27989 r = read onlyCrip); 
27990 

27991 if Crip != old rip) put inodeCrip); 
27992 

27993 return(r); 

27994 + 


27996 /$====D=DD=DDDD=DD>=D=>=D=>>DDD>D>=>>02=>>>D==DD>=>D==>>D=>=======2=>>"==>=0=>============ * 

27997 x read only * 

27998 EDDODSDSDODODODODODODDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD>>DD>>>>=>>>=>=>>====>==== * / 

27999 PUBLIC int read onlyCip) 

28000 struct inode “ip; /* ptr para i-node cujo sis de arquivos deve ser verif */ 
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28001 { 

28002 /* Verifica se o sistema de arquivos no qual o i-node "ip" reside está montado 
28003 * somente para leitura. Se estiver, retorna EROFS, senão retorna OK. 

28004 xy 

28005 

28006 register struct super_block *sp; 

28007 

28008 sp = ip->i sp; 

28009 return(sp->s rd only ? EROFS : OK); 

28010 } 


HHHHHEHHHHHHH+ HEHHE HHHH HHHH HHHH HHHH HH HHHH HHHH HHHH O O O O DO OO OD O O O 
servers/fs/dmap.c 


HHHHHHHHHH+H HH HHHH HHHH HHHH HH HHH H+H HHHH HHHH HHHH H+H HHHH H+ HHH HHHH HH+H+HH+H+H+H+H+H+ 


28100 /* Este arquivo contém a tabela com mapeamentos dispositivo <-> driver. Ele também 


28101 * contém algumas rotinas para adicionar e/ou remover drivers de dispositivo dinamicamente 
28102 * ou para alterar mapeamentos. 

28103 */ 

28104 


28105 #include "fs.h" 

28106 #include "fproc.h" 

28107 #include <string.h> 

28108 #include <stdlib.h> 

28109 #include <ctype.h> 

28110 #include <unistd.h> 

28111 #include <minix/com.h> 

28112 #include "param.h" 

28113 

28114 /* Alguns dispositivos podem ou não estar na próxima tabela. */ 
28115 #define DT(enable, opcl, io, driver, flags) \ 
28116 { Cenable?(opcl):no_dev), (enable?(io):0), \ 


28117 (enable? (driver):0), (flags) }, 

28118 #define NC(x) (NR CTRLRS >= (x)) 

28119 

28120 /* A ordem das entradas aqui determina o mapeamento entre números de 

28121 * dispositivo principal e tarefas. A primeira entrada (dispositivo principal 0) não é 
28122 * usada. A entrada seguinte é o dispositivo principal 1 etc. Dispositivos de caractere e 
28123 * bloco podem ser misturados aleatoriamente. A ordem determina os números de dispositivo 
28124 * em /dev/.Note que o FS conhece o número de dispositivo de /dev/ram/ para carregar o disco 
28125 * de RAM. Note também que os números de dispositivo principal usados em /dev/ NÃO são 
28126 * iguais aos números de processo dos drivers de dispositivo. 

28127 */ 

28128 /* 

28129 Driver ativado Open/Cls E/S Nº do driver Flags Dispositivo Arquivo 

28130 — -------------- —  -------- ------ ----------- ----- ------ ---- 

28131 */ 

28132 struct dmap dmap[NR DEVICES]; /* mapa real */ 

28133 PRIVATE struct dmap init dmap[] = { 

28134 DT(1, no dev, 0, 0, 0) /* O = não utilizado */ 

28135 DT(1, gen opcl, gen io, MEM PROC NR, 0) /* 1 = /dev/mem */ 

28136 DT(O, no dev, 0, 0, DMAP MUTABLE) /* 2 = /dev/fdo ETA 

28137 DT(O, no dev, 0, 0, DMAP MUTABLE) /* 3 = /dev/c0 */ 

28138 DT(1, tty opcl, gen io, TTY PROCNR, 0) /* 4 = /dev/tty00 */ 

28139 DT(1, ctty opcl,ctty io, TTY PROC NR, 0) /* 5 = /dev/tty */ 

28140 DT(O, no dev, 0, NONE, DMAP MUTABLE) /* 6 = /dev/lp */ 

28141 DT(1, no dev, 0, 0, DMAP MUTABLE) /* 7 = /dev/ip E/ 

28142 DT(O, no dev, 0, NONE, DMAP MUTABLE) /* 8 = /dev/cl KY 

28143 DT(O, O, 0, 0, DMAP_MUTABLE) /* 9 = não utilizado */ 

28144 DT(0, no dev, 0; 0, DMAP MUTABLE) /*10 = /dev/c2 */ 
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28145 DT(O, O, 0, 0, DMAP MUTABLE) /*11 = não utilizado */ 
28146 DT(O, no dev, 0, NONE, DMAP MUTABLE) /*12 = /dev/c3 */ 

28147 DT(O, no dev, 0, NONE, DMAP MUTABLE) /*13 = /dev/audio */ 
28148 DT(O, no dev, O; NONE, DMAP_MUTABLE) /*14 = /dev/mixer */ 
28149 DT(1, gen opcl, gen io, LOG PROC NR, 0) /*15 = /dev/klog */ 
28150 DT(O, no dev, Oi; NONE, DMAP_MUTABLE) /*16 = /dev/random*/ 
28151 DT(O, no dev, O:; NONE, DMAP MUTABLE) /*17 = /dev/cmos */ 
28152 5; 

28153 

28154 [f==DDDDDD=D0D5>D0 0520 DDDOSDODD ODDS DDD SDDCSSDDESDDEDS SSD DDD 
28155 * do devct1 # 
28156 OCDE ee / 
28157 PUBLIC int do devctl O 

28158 { 

28159 int result; 

28160 

28161 switch(m in.ctl reg) 1 

28162 case DEV MAP: 

28163 /* Tenta atualizar o mapeamento de dispositivos. */ 

28164 result = map driver(m in.dev nr, m in.driver nr, m in.dev style); 

28165 break; 

28166 case DEV UNMAP: 

28167 result = ENOSYS; 

28168 break; 

28169 default: 

28170 result = EINVAL; 

28171 3 

28172 return(result); 

28173 } 

28175  [/f====>======>=>======>=5 HH 
28176 x map_driver * 
28177 A 
28178 PUBLIC int map_driver(major, proc_nr, style) 

28179 int major; /* número principal do dispositivo */ 

28180 int proc_nr; /* número de processo do driver */ 

28181 int style; /* estilo do dispositivo */ 

28182 { 

28183 /* Configura um novo mapeamento de driver de dispositivo na tabela dmap. Dado que 
28184 * são fornecidos argumentos corretos, isso só funciona se a entrada for mutável e o 
28185 * driver corrente não estiver ocupado. 

28186 * Os códigos de erro normais são retornados para que essa função possa ser usada a 
28187 * partir de uma chamada de sistema que tenta instalar um novo driver dinamicamente. 
28188 A, 

28189 struct dmap *dp; 

28190 

28191 /* Obtém ponteiro para entrada de dispositivo na tabela dmap. */ 


28192 if (major >= NR DEVICES) return(ENODEV) ; 

28193 dp = &dmap [major]; 

28194 

28195 /* Verifica se é permitido atualizar a entrada. */ 
28196 if (C! (dp->dmap flags & DMAP MUTABLE)) return(EPERM); 
28197 if (dp->dmap flags & DMAP BUSY) return(EBUSY); 


28198 

28199 /* Verifica o número de processo do novo driver. */ 
28200 if (! isokprocnr(proc nr)) return(EINVAL); 

28201 

28202 /* Tenta atualizar a entrada. */ 


28203 switch (style) 1 
28204 case STYLE DEV: dp->dmap opcl = gen opcl; break; 
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28205 
28206 
28207 
28208 
28209 
28210 
28211 
28212 


28214 
28215 
28216 
28217 
28218 
28219 
28220 
28221 
28222 
28223 
28224 
28225 
28226 
28227 
28228 
28229 
28230 
28231 
28232 
28233 
28234 
28235 
28236 
28237 
28238 
28239 
28240 
28241 
28242 
28243 
28244 
28245 
28246 
28247 
28248 
28249 
28250 
28251 
28252 
28253 
28254 
28255 
28256 
28257 
28258 
28259 
28260 
28261 
28262 
28263 
28264 


case STYLE TTY: dp->dmap opcl = tty opcl; break; 
case STYLE CLONE: dp->dmap opcl = clone opcl; break; 
default: return (EINVAL); 

} 


dp->dmap_io = gen_io; 
dp->dmap_driver = proc_nr; 
return(0K); 


PUBLIC void build dmapQO 

{ 

/* Inicializa a tabela com todos os mapeamentos dispositivo <-> driver. Em seguida, faz o 
* mapeamento do driver de inicialização em uma controladora e atualiza a tabela dmap com 
* essa seleção. O driver de inicialização e a controladora que ele manipula são configurados 

* no monitor de inicialização. 

27 
char driver[16]; 
char *controller = "c##"; 
int nr, major = -1; 
int i,s; 
struct dmap *dp; 


/* Constrói a tabela com mapeamentos dispositivo <-> driver. */ 
for (i=0; i<NR DEVICES; i++) { 
dp = &dmap[il; 
if Ci < sizeof(init dmap)/sizeof(struct dmap) && 
init dmap[i].dmap opcl != no dev) { /* um driver previamente configurado */ 
dp->dmap opcl = init dmap[i].dmap opcl; 
dp->dmap io = init dmap[il].dmap io; 
dp->dmap driver = init dmap[i].dmap driver; 
dp->dmap flags = init dmap[il].dmap flags; 
} else { /* nenhum padrão */ 
dp->dmap_opcl = no_dev; 
dp->dmap_io = 0; 
dp->dmap_driver = 0; 
dp->dmap_flags = DMAP_MUTABLE; 


} 


/* Obtém configurações de "controller" e "driver" no monitor de inicialização. */ 
if (Cs = env get param("label", driver, sizeof(driver))) != OK) 


panic(. FILE ,"couldn't get boot monitor parameter "driver"", s); 
if (Cs = env get param("controller", controller, sizeof(controller))) != OK) 
panic(. FILE ,"couldn't get boot monitor parameter 'controller"", s); 


/* Determina o número principal para fazer o mapeamento do driver. */ 
if (controller[0] == 'f” && controller[1] == ’d’) { 
major = FLOPPY MAJOR; 


} 
else if (controller[0] == °c’? && isdigit(controller[1])) { 
if (Cnr = (unsigned) atoi (&controller[1])) > NR_CTRLRS) 
panic(. FILE ,"monitor "controller" maximum "cg" is", NR_CTRLRS); 
major = CTRLR(nr); 
} 
else { 


panic( FILE ,"monitor ’controller’? syntax is 'c&' of "fd'", NO NUM); 
} 
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28267 
28268 
28269 
28270 
28271 


/* Agora tenta configurar o mapeamento real e informar o usuário. */ 

if ((s=map driver(major, DRVR PROC NR, STYLE DEV)) != OK) 
panic(. FILE ,"map driver failed",s); 

printf("Boot medium driver: %s driver mapped onto controller %s An”, 
driver, controller); 
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28300 
28301 
28302 
28303 
28304 
28305 
28306 
28307 
28308 
28309 
28310 
28311 
28312 
28313 
28314 
28315 
28316 
28317 
28318 
28319 
28320 
28321 
28322 
28323 
28324 
28325 
28326 
28327 
28328 
28329 
28330 
28331 
28332 
28333 
28334 
28335 
28336 
28337 
28338 
28339 
28340 
28341 
28342 
28343 
28344 


/* Quando um bloco necessário não está na cache, ele deve ser buscado do disco. 
* Os arquivos especiais de caractere também exigem E/S. As rotinas para eles estão aqui. 


* Os pontos de entrada neste arquivo são: 


* dev open: o FS abre um dispositivo 
* dev close: o FS fecha um dispositivo 
dev io: o FS faz uma leitura ou uma escrita em um dispositivo 
* dev status: o FS processa o alerta de requisição de callback 
* gen opcl: chamada genérica para uma tarefa executar uma abertura/fechamento 
*  genio: chamada genérica para uma tarefa executar uma operação de E/S 
* no dev: processamento de abertura/fechamento para dispositivos que não existem 
*  tty opcl: faz processamento específico de tty para abertura/fechamento 
*  ctty opcl: faz processamento específico de tty de controle p/ abertura/fechamento 
*  cttyio: realiza processamento específico de tty de controle para E/S 
* do ioctl: executa a chamada de sistema IOCTL 
* do setsid: executa a chamada de sistema SETSID (no lado do SA) 


tinclude "fs.h" 

ginclude <fcntl.h> 
tinclude <minix/calinr.h> 
tinclude <minix/com.h> 
tinclude "file.h" 
ginclude "fproc.h" 
ginclude "inode.h" 
tinclude "param.h" 


tdefine ELEMENTS(a) (sizeof(a)/sizeof((a) [0])) 


extern int dmap size; 


PUBLIC int dev open(dev, proc, flags) 


dev t dev; /* dispositivo a ser aberto */ 
int proc; /* processo para o qual abrir */ 
int flags; /* bits de modo e flags */ 

{ 


int major, r; 
struct dmap *dp; 


/* Determina o número de dispositivo principal que chama a rotina de abertura/fechamento 
* específica da classe do dispositivo. (Essa é a única rotina que deve verificar se o nú- 
* mero de dispositivo está no intervalo. Todas as outras podem confiar nessa verificação.) 
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28345 
28346 
28347 
28348 
28349 
28350 
28351 
28352 


28354 
28355 
28356 
28357 
28358 
28359 
28360 
28361 


28363 
28364 
28365 
28366 
28367 
28368 
28369 
28370 
28371 
28372 
28373 
28374 
28375 
28376 
28377 
28378 
28379 
28380 
28381 
28382 
28383 
28384 
28385 
28386 
28387 
28388 
28389 
28390 
28391 
28392 
28393 
28394 
28395 
28396 
28397 
28398 
28399 
28400 
28401 


Hj 
major = (dev >> MAJOR) & BYTE; 

if (major >= NR DEVICES) major = 0; 

dp = &dmap [major]; 

r = (*dp->dmap opcl)(DEV OPEN, dev, proc, flags); 

if (r == SUSPEND) panic( FILE ,"suspend on open from", dp->dmap driver); 
return(r); 


} 

/* Sp a O O TT ——.———————.—————e——o————— A 
* dev close * 
E EDDS==D=D=D>=>>=>>=>>=>>=>=>=>=>>=>>=>>=>>=>=>>=>>=>=>>>>=>=>>=>=>>>>>>>=>>=>>>>>>=>>=>>=>===>===> * / 

PUBLIC void dev close(dev) 

dev t dev; /* dispositivo a ser fechado */ 

{ 

(void) (*dmap[(dev >> MAJOR) & BYTE] .dmap_opc1)(DEV_CLOSE, dev, O, 0); 

} 

JŽ ======= * 
* dev status * 
À E E E E */ 

PUBLIC void dev status (message *m) 

{ 

message st; 
int d, get_more = 1; 
for(d = 0; d < NR DEVICES; d++) 
if (dmap[d].dmap_driver == m->m source) 
break; 
if (d >= NR_DEVICES) 
return; 
do { 
int r; 
st.m_type = DEV_STATUS; 
if ((r=sendrec(m->m source, &st)) != OK) 
panic(. FILE ,"couldn't sendrec for DEV STATUS”, r); 
switch(st.m type) 1 
case DEV REVIVE: 
revive(st.REP PROC NR, st.REP STATUS); 
break; 
case DEV IO READY: 
select notified(d, st.DEV MINOR, st.DEV SEL OPS); 
break; 
default: 
printfC"FS: unrecognized rep %d to DEV STATUSAn",st.m type); 
/* Falha. */ 


case DEV NO STATUS: 
get more = 0; 
break; 
} 


} while(get_more); 


return; 
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28403 — /*======= a * 
28404 * dev io * 
28405 E CODSDSSSSSSSDDSSDDSSD=D===================================================== * / 


28406 PUBLIC int dev io(op, dev, proc, buf, pos, bytes, flags) 

28407 int op; /* DEV READ, DEV WRITE, DEV IOCTL, etc. */ 

28408 dev t dev; /* número de dispositivo principal-secundário */ 
28409 int proc; /* o buf está no espaço de endereçamento de quem? */ 
28410 void *buf; /* endereço virtual do buffer */ 

28411 off t pos; /* posição do byte */ 

28412 int bytes; /* quantos bytes serão transferidos */ 

28413 int flags; /* flags especiais, como O NONBLOCK */ 

28414 { 

28415 /* Lê ou escreve de um dispositivo. O parâmetro "dev" informa o que é. */ 

28416 struct dmap *dp; 

28417 message dev mess; 

28418 

28419 /* Determina dmap da tarefa. */ 

28420 dp = &dmap[ (dev >> MAJOR) & BYTE]; 


28421 

28422 /* Configura a mensagem passada para a tarefa. */ 
28423 dev mess.m type = op; 

28424 dev mess.DEVICE = (dev >> MINOR) & BYTE; 


28425 dev mess. POSITION = pos; 

28426 dev mess.PROC NR = proc; 

28427 dev mess.ADDRESS = buf; 

28428 dev mess.COUNT = bytes; 

28429 dev mess.TTY FLAGS = flags; 

28430 

28431 /* Chama a tarefa. */ 

28432 C*dp->dmap io) (dp->dmap driver, &dev mess); 


28433 

28434 /* A tarefa terminou. Verifica se a chamada terminou. */ 

28435 if (dev mess.REP STATUS == SUSPEND) { 

28436 if (flags & O NONBLOCK) 1 

28437 /* Não deve bloquear. */ 

28438 dev mess.m type = CANCEL; 

28439 dev mess.PROC NR = proc; 

28440 dev mess.DEVICE = (dev >> MINOR) & BYTE; 

28441 (C*dp->dmap io) (dp->dmap driver, &dev mess); 

28442 if (dev mess.REP STATUS == EINTR) dev mess.REP STATUS = EAGAIN; 
28443 } else { 

28444 /* Suspende o usuário. */ 

28445 suspend(dp->dmap_driver); 

28446 return (SUSPEND); 

28447 } 

28448 } 

28449 return(dev mess.REP STATUS); 

28450 + 

28452 0  /f========DD=D=DD=D=D===DDDDD>=DDD=DDDD=2>D=D=>>D=2=D==2D==D>>==>==>>==>===>==>======>======== * 
28453 y gen opcl fe 
28454 fooonDDDDDoooD=DDDDDDocoDDDDDDooonDDDDDDDoooDDDDDocecnDoDDDcooonnoDooconono=*/ 
28455 PUBLIC int gen opcl(op, dev, proc, flags) 

28456 int op; /* operação, DEV OPEN ou DEV CLOSE */ 

28457 dev t dev; /* dispositivo a abrir ou fechar */ 

28458 int proc; /* processo para o qual vai abrir/fechar */ 
28459 int flags; /* bits de modo e flags */ 


28460 { 
28461 /* Chamada a partir de dmap em table.c em abertura e fechamento de arquivos especiais. */ 
28462 struct dmap *dp; 
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28463 message dev mess; 


28465 /* Determina dmap da tarefa. */ 
28466 dp = &dmap[ (dev >> MAJOR) & BYTE]; 


28468 dev mess.m type = op; 

28469 dev mess.DEVICE (dev >> MINOR) & BYTE; 
28470 dev mess.PROC NR = proc; 

28471 dev mess. COUNT flags; 


28473 /* Chama a tarefa. */ 
28474 (C*dp->dmap io) (dp->dmap driver, &dev mess); 


28476 return(dev mess.REP STATUS); 


28482 PUBLIC int tty opcl(op, dev, proc, flags) 


28483 int op; /* operação, DEV OPEN ou DEV CLOSE */ 

28484 dev t dev; /* dispositivo a ser aberto ou fechado */ 
28485 int proc; /* processo para o qual vai abrir/fechar */ 
28486 int flags; /* bits de modo e flags */ 


28487 1 
28488 /* Esta função é chamada a partir da estrutura dmap na abertura/fechamento de tty. */ 


28490 int r; 


28491 register struct fproc “rfp; 

28492 

28493 /* Adiciona O NOCTTY nos flags, caso este processo não seja líder de sessão ou 
28494 * se já tiver um tty de controle ou, ainda, se for o tty de controle 

28495 * de outra pessoa. 

28496 */ 

28497 if (!fp->fp_sesldr || fp->fp_tty != 0) { 

28498 flags |= O NOCTTY; 

28499 } else { 

28500 for (rfp = &fproc[0]; rfp < &fproc[NR_PROCS]; rfp++) { 

28501 if Crfp->fp tty == dev) flags |= O NOCTTY; 

28502 

28503 

28504 

28505 r = gen opcl(op, dev, proc, flags); 

28506 

28507 /* Essa chamada transformou o tty no tty de controle? */ 

28508 if rD { 

28509 fp->fp_tty = dev; 

28510 r= OK; 

28511 } 

28512 return(r); 

28513 } 

28515. /f=========D==D======D=DD=DD>=DDD=D=2DD=DD>>=2>>=>=2=D==2=>==>>==>>==>====>===>===>============== * 
28516 ii ctty opcl * 
28517 FESSESDSSDCSSS=DSD SD SSSSDSSSDDS e ESSES ESEs=== 22% / 
28518 PUBLIC int ctty opcl(op, dev, proc, flags) 

28519 int op; /* operação, DEV OPEN ou DEV CLOSE */ 

28520 dev t dev; /* dispositivo a ser aberto ou fechado */ 
28521 int proc; /* processo para o qual vai abrir/fechar */ 


28522 int flags; /* bits de modo e flags */ 
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28523 
28524 
28525 
28526 
28527 
28528 
28529 


28531 
28532 
28533 
28534 
28535 
28536 
28537 
28538 
28539 
28540 
28541 
28542 
28543 
28544 
28545 
28546 
28547 
28548 
28549 


28551 
28552 
28553 
28554 
28555 
28556 
28557 
28558 
28559 
28560 
28561 
28562 
28563 
28564 
28565 
28566 
28567 
28568 
28569 
28570 


28572 
28573 
28574 
28575 
28576 
28577 
28578 
28579 
28580 
28581 
28582 


{ 
/* Esta função é chamada a partir da estrutura dmap em table.c na abertura/fechamento 
* de /dev/tty, o dispositivo mágico que se transforma no tty de controle. 


*/ 


return(fp->fp_tty == 0 ? ENXIO : OK); 


PUBLIC int do_setsidO 

{ 

/* Executa o lado do FS da chamada de SETSID; isto é, se desfaz do 

* terminal de controle de um processo e transforma o processo no líder de sessão. 
#/ 


register struct fproc *rfp; 


/* Apenas o MM pode fazer a chamada de SETSID diretamente. */ 
if (who != PM PROC NR) return(ENOSYS); 


/* Transforma o processo em um líder de sessão sem tty de controle. */ 
rfp = &fproc[m_in.slot1]; 

rfp->fp_sesldr = TRUE; 

rfp->fp_tty = 0; 

return(OK) ; 


PUBLIC int do_ioctl O 
{ 


/* Executa a chamada de sistema ioctl(ls_fd, request, argx) (usa formato m2). */ 


struct filp *f; 
register struct inode *rip; 
dev t dev; 


if C(f=9et filp(min.ls fd)) == NIL FILP) return(err code); 
rip = f->filp ino; /* obtém ponteiro de i-node */ 
if C Crip->i mode & I TYPE) != I CHAR SPECIAL 
&& (rip->i mode & I TYPE) != T BLOCK SPECIAL) return(ENOTTY); 
dev = (dev t) rip->i zone[0]; 


return(dev io(DEV IOCTL, dev, who, m in.ADDRESS, OL, 
m in.REQUEST, f->filp flags)); 


} 

Jin 
i gen_io * 
ARS E E + / 

PUBLIC void gen_io(task_nr, mess_ptr) 

int task_nr; /* qual tarefa vai chamar */ 

message *mess_ptr; /* ponteiro para mensagem da tarefa */ 

{ 


/* Em última análise, toda E/S do FS é proveniente da E/S nos pares dispositivo principal/ 
* secundário. Isso leva às chamadas das rotinas a seguir por meio da tabela dmap. 


E, 
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28583 
28584 
28585 
28586 
28587 
28588 
28589 
28590 
28591 
28592 
28593 
28594 
28595 
28596 
28597 
28598 
28599 
28600 
28601 
28602 
28603 
28604 
28605 
28606 
28607 
28608 
28609 
28610 
28611 
28612 
28613 
28614 
28615 
28616 
28617 
28618 
28619 
28620 
28621 
28622 
28623 
28624 
28625 
28626 
28627 
28628 
28629 
28630 
28631 
28632 
28633 
28634 
28635 
28636 
28637 
28638 
28639 
28640 
28641 
28642 


int r, proc nr; 
message local m; 


proc nr = mess ptr->PROC NR; 
if (! isokprocnr(proc nr)) 1 
printfC"FS: warning, got illegal process number (%d) from %d\n", 
mess ptr->PROC NR, mess ptr->m source); 
return; 


} 


while (Cr = sendrec(task nr, mess ptr)) == ELOCKED) { 
/* sendrec() falhou para evitar um impasse. A tarefa "task nr” está 
* tentando enviar uma mensagem REVIVE de uma requisição anterior. 
* Trata dela e tenta novamente. 
*/ 
if (Cr = receive(task_nr, &local_m)) != OK) { 
break; 


} 


/* Se era uma msg de cancelamento para uma tarefa que acabou de enviar uma 
* O chamador desta função executará ‘revive’ para o processo. 
*/ 
if (mess_ptr->m_type == CANCEL && local_m.REP_PROC_NR == proc_nr) { 
return; 


} 


/* Caso contrário, deve ser REVIVE. */ 
if (local m.m type != REVIVE) { 
printf 
"fs: strange device reply from %d, type = %d, proc = %d (1)\n", 
local m.m source, 
local m.m type, local m.REP PROC NR); 
continue; 


} 


revive(local_m.REP_PROC_NR, local_m.REP_STATUS); 
} 


* resposta de conclusão, ignora a resposta e aborta requisição de cancelamento 


/* A mensagem recebida pode ser resposta para esta chamada ou uma operação REVIVE de 


* algum outro processo. 


i 
for GD) £ 
if Cr != 0K} { 
if (r == EDEADDST) return; /* abandona */ 
else panic( FILE ,"call task: can't send/receive”, r); 
} 


/* O processo para o qual executamos sendrec() obteve um resultado? */ 
if (mess ptr->REP PROC NR == proc nr) { 

break; 
} else if (mess ptr->m type == REVIVE) 1 

/* Caso contrário, deve ser REVIVE. */ 

revive(mess ptr->REP PROC NR, mess ptr->REP STATUS); 


} else { 
printfc 
"fs: strange device reply from %d, type = %d, proc = %d (2) in", 
mess ptr->m source, 
mess ptr->m type, mess ptr->REP PROC NR); 
return; 
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28643 } 

28644 

28645 r = receive(task_nr, mess_ptr); 

28646 } 

28647 } 

28649 /* === 
28650 x ctty io * 
28651 FoSESSSDSSSSSSESSSSSSSSSSSSSSESS SSD SEDE ES DOSES SSD E sã / 
28652 PUBLIC void ctty io(task nr, mess ptr) 

28653 int task nr; /* não utilizado - para compatibilidade com dmap t */ 
28654 message “mess ptr; /* ponteiro para mensagem da tarefa */ 

28655 { 

28656 /* Esta rotina só é chamada para um dispositivo, a saber, /dev/tty. Sua tarefa 
28657 * é mudar a mensagem para usar o terminal de controle, em vez do par 

28658 * principal/secundário do próprio /dev/tty. 

28659 */ 

28660 

28661 struct dmap *dp; 

28662 

28663 if Cfp->fp tty == 0) { 

28664 /* Mais nenhum tty de controle presente, retorna um erro de E/S. */ 
28665 mess ptr->REP STATUS = EIO; 

28666 } else { 

28667 /* Substitui o dispositivo de terminal de controle. */ 

28668 dp = &dmap[(fp->fp_tty >> MAJOR) & BYTE]; 

28669 mess_ptr->DEVICE = (fp->fp_tty >> MINOR) & BYTE; 

28670 (*dp->dmap_io)(dp->dmap_driver, mess ptr); 

28671 } 

28672 } 

28674 /* === Ý 
28675 E no dev 
28676 fEEESSSSSSSSSSDSSSDSSSSSSSSSSE SS SEE DSSSSDSSSSSSS SESC SS ESSES EDSSS DESSE / 
28677 PUBLIC int no dev(op, dev, proc, flags) 

28678 int op; /* operação, DEV OPEN ou DEV CLOSE */ 

28679 dev t dev; /* dispositivo a ser aberto ou fechado */ 

28680 int proc; /* processo para o qual vai abrir/fechar */ 
28681 int flags; /* bits de modo e flags */ 

28682 1 

28683 /* Chamada ao se abrir um dispositivo inexistente. */ 

28684 

28685 return(ENODEV) ; 

28686 + 

28688  /*===DD=D>D>D>DDDDDDDDDDDDDD0DDDDDDDD0D0DDDDDDDD0D0DDDDDDD>D=DD=>D=>=>=>>=>=>=>>=>* 
28689 E clone opcl * 
28690 ÉS SEDE / 
28691 PUBLIC int clone opcl(op, dev, proc, flags) 

28692 int op; /* operação, DEV OPEN ou DEV CLOSE */ 

28693 dev t dev; /* dispositivo a ser aberto ou fechado */ 

28694 int proc; /* processo para o qual vai abrir/fechar */ 
28695 int flags; /* bits de modo e flags */ 

28696 1 

28697 /* Alguns dispositivos precisam de processamento especial na abertura. Tais dispositivos são 
28698 * "clonados",isto é, no caso de uma abertura bem-sucedida, eles são substituídos por um 
28699 * novo nro de dispositivo secundário exclusivo. Esse novo número de dispositivo identifica 
28700 * um novo objeto (como uma nova conexão de rede) que foi alocado dentro de uma tarefa. 
28701 */ 


28702 struct dmap *dp; 
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28703 
28704 
28705 
28706 
28707 
28708 
28709 
28710 
28711 
28712 
28713 
28714 
28715 
28716 
28717 
28718 
28719 
28720 
28721 
28722 
28723 
28724 
28725 
28726 
28727 
28728 
28729 
28730 
28731 
28732 
28733 
28734 
28735 
28736 
28737 
28738 
28739 
28740 
28741 
28742 


int minor; 
message dev mess; 


/* Determina a dmap da tarefa. */ 
dp = &dmap[ (dev >> MAJOR) & BYTE]; 
minor = (dev >> MINOR) & BYTE; 


dev mess.m type = op; 
dev mess.DEVICE = minor; 
dev mess.PROC NR = proc; 
dev mess.COUNT = flags; 


/* Chama a tarefa. */ 
C*dp->dmap io) (dp->dmap driver, &dev mess); 


if Cop == DEV OPEN && dev mess.REP STATUS >= 0) 1 
if (dev mess.REP STATUS != minor) { 
/* Um novo número de dispositivo secundário foi retornado. Cria um 
* arquivo de dispositivo temporário para armazená-lo. 
*/ 


struct inode *ip; 


/* Número de dispositivo do novo dispositivo. */ 
dev = (dev & “(BYTE << MINOR)) | (dev mess.REP STATUS << MINOR); 


ip = alloc inode(root dev, ALL MODES | I CHAR SPECIAL); 

if Cip == NIL INODE) 1 
/* Opa, isso não funcionou. Desfaz a abertura. */ 
(void) clone opci(DEV CLOSE, dev, proc, 0); 
return(err code); 

} 


ip->i_zone[0] = dev; 


put_inode(fp->fp_filp[m_in.fd]->filp_ino); 
fp->fp_filp[m_in.fd]->filp_ino = ip; 
} 
dev_mess.REP_STATUS = OK; 
} 
return(dev mess.REP STATUS); 
} 


HEHEHEHEH HEHH H+H HH HHHH H+H H+ HH HHH H+H HHHH HHHH ++ 
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28800 
28801 
28802 
28803 
28804 
28805 
28806 
28807 
28808 
28809 


/* Este arquivo trata das chamadas de sistema que lidam com o tempo. 
* Os pontos de entrada para este arquivo são 
* do_utime: executa a chamada de sistema UTIME 
* do_stime: o PM informa ao FS sobre a chamada de sistema STIME 


ga 


#include "fs.h" 
#include <minix/callnr.h> 
#include <minix/com.h> 
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28810 
28811 
28812 
28813 
28814 
28815 
28816 
28817 
28818 
28819 
28820 
28821 
28822 
28823 
28824 
28825 
28826 
28827 
28828 
28829 
28830 
28831 
28832 
28833 
28834 
28835 
28836 
28837 
28838 
28839 
28840 
28841 
28842 
28843 
28844 
28845 
28846 
28847 
28848 
28849 
28850 
28851 
28852 
28853 
28854 


28856 
28857 
28858 
28859 
28860 
28861 
28862 
28863 
28864 


tinclude "file.h" 
tinclude "fproc.h" 
ginclude "inode.h" 
tinclude "param.h" 


PUBLIC int do utime() 
{ 


/* Executa a chamada de sistema utime(name, timep). */ 


register struct inode *rip; 
register int len, r; 


/* Ajuste para o caso de "timep” ser NULL; 
* então, utime_strlen contém o tamanho real: strlen(name)+1. 


*/ 
len = m in.utime length; 
if (len == 0) len = m in.utime strlen; 


/* Abre o arquivo temporariamente. */ 
if (fetch name(m in.utime file, len, M1) != OK) return(err code); 
if C Crip = eat path(user path)) == NIL INODE) return(err code); 


/* Somente o proprietário de um arquivo ou o superusuário podem alterar seu tempo. 


r=0K; 
if Crip->i uid != fp->fp effuid && !super user) r = EPERM; 
if (m in.utime length == 0 && r != OK) r = forbiddenClrip, W BIT); 
if (read onlyCrip) != OK) r = EROFS; /* nem mesmo o su pode tocar, se for R/O */ 
if (r == OK) É 
if (m in.utime length == 0) 1 
rip->i atime = clock time(Q); 
rip->i mtime = rip->i atime; 
} else { 
rip->i_atime = m_in.utime_actime; 
rip->i_mtime = m_in.utime_modtime; 
} 
rip->i_update = CTIME; /* descarta todos os flags ATIME e MTIME velhos */ 
rip->i_dirt = DIRTY; 
} 


put_inode(rip); 
return(r); 


PUBLIC int do stime() 

{ 

/* Executa a chamada de sistema stime(tp). */ 
boottime = (long) m_in.pm_stime; 
return(0K); 
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00600 include/string.h 
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04400 include/ibm/interrupt.h 
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03000 include/minix/ipc.h 
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03200 include/minix/syslib.h 
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02100 include/sys/ioc disk.h 
02000 include/sys/ioctl.h 
01600 include/sys/sigcontext.h 
01700 include/sys/stat.h 
01400 include/sys/types.h 
01900 include/sys/wait.h 
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11000 drivers/libdriver/driver.c 
10800 drivers/libdriver/driver.h 
11400 drivers/libdriver/drvlib.c 
10900 drivers/libdriver/drvlib.h 
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15900 drivers/tty/console.c 
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04700 kernel/config.h 
04800 kernel/const.h 
08000 kernel/exception.c 
05300 kernel/glo.h 
08100 kernel/18259.c 
05400 kernel/ipc.h 
04600 kernel/kernel.h 
08700 kernel/klib.s 
08800 kernel/klib386.s 
07100 kernel/main.c 
06200 kernel/mpx.s 
06300 kernel/mpx386.s 
05700 kernel/priv.h 
07400 kernel/proc.c 
05500 kernel/proc.h 
08300 kernel/protect.c 
05800 kernel/protect.h 
05100 kernel/proto.h 
05600 kernel/sconst.h 
06900 kernel/start.c 
09700 kernel/system.e 
09600 kernel/system.h 
10300 kernel/system/do exec.c 
10200 kernel/system/do setalarm.c 
06000 kernel/table.c 
04900 kernel/type.h 
09400 kernel/utility.e 
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28300 servers/fs/device.c 
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21700 servers/fs/file.h 
23700 servers/fs/filedes.c 
21500 servers/fs/fproc.h 
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22900 servers/fs/inode.c 
21900 servers/fs/inode.h 
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23800 servers/fs/lock.c 
21800 servers/fs/lock.h 
24000 servers/fs/main.c 
26700 servers/fs/mount.c 
24500 servers/fs/open.c 
22000 servers/fs/param.h 
26300 servers/fs/path.c 
25900 servers/fs/pipe.c 
27800 servers/fs/protect.c 
21200 servers/fs/proto.h 
25000 servers/fs/read.c 
27500 servers/fs/stadir.c 
23300 servers/fs/super.c 
22100 servers/fs/super.h 
22200 servers/fs/table.c 
28800 servers/fs/time.c 
21100 servers/fs/type.h 
25600 servers/fs/write.c 
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17100 servers/pm/const.h 
18700 servers/pm/exec.c 
18400 servers/pm/forkexit.c 
20400 servers/pm/getset.c 
17500 servers/pm/glo.h 
18000 servers/pm/main.c 
20500 servers/pm/misc.c 
17600 servers/pm/mproc.h 
17700 servers/pm/param.h 
17000 servers/pm/pm.h 
17300 servers/pm/proto.h 
19500 servers/pm/signal.c 
17800 servers/pm/table.c 
20300 servers/pm/time.c 
20200 servers/pm/timers.c 
17200 servers/pm/type.h 
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SOBRE O CD DO MINIX 3 


REQUISITOS DE SISTEMA 


A seguir está uma lista dos requisitos mínimos para instalar o software fornecido neste CD. 


HARDWARE 

O MINIX 3 OS exige o seguinte hardware: 

e PC com um processador Pentium ou compatível 
e 16 Mb ou mais de memória RAM 

e 200 Mb de espaço livre no disco 

e driver de CD-ROM IDE 

e disco rígido IDE 


Não suportados: discos ATA, USB e SCSI seriais não são suportados. Para configurações alternativas, 
visite o endereço http://www.minix3.org 


SOFTWARE 


O MINIX 3 OS é um sistema operacional. Se você quiser manter o sistema operacional existente e 
seus dados (recomendado) e criar uma máquina de inicialização dupla, então precisará particionar sua 
unidade de disco rígido. Você pode usar uma das seguintes opções: 


e Partition Magic (http://www.powerquest.com/partitionmagic) 
ou 

e The Partition Resizer (http://www.zeleps.com) 
ou 


e Seguir as instruções que aparecem no endereço http://www.minix3.org/partitions.html 


INSTALAÇÃO 


A instalação pode ser completada sem uma conexão ativa com a internet, mas você pode encontrar a 
documentação avançada no endereço http://www.minix3.org. Instruções de instalação completas são 
fornecidas no CD, no formato Adobe Acrobat PDF. 


SUPORTE DO PRODUTO 


Para obter mais informações técnicas sobre o software MINIX deste CD, visite o site da Web oficial do 
MINIX, no endereço http://www.minix3.org 


TERMOS DE USO E ISENÇÃO DE GARANTIAS 


Leia com atenção 


O conteúdo deste CD está protegido por direitos autorais e está sendo licenciado a você somente para o uso 
pessoal, a menos que tenha sido vendido para ser usado especificamente em rede. Você não pode transferir 
nem distribuir este conteúdo sob qualquer forma, nem mesmo via Internet. Exceto para uma cópia de 
segurança, você não pode copiar este material nem a documentação. Você não pode reengenherizar, desmontar, 
descompilar, modificar, adaptar, traduzir ou criar trabalhos derivados do material ou da documentação. Você 
pode ser acionado judicialmente por cópia ou transferência ilegal. 


O conteúdo deste CD é fornecido como está, sem garantias. Os autores, os revendedores e a Bookman Editora 
não possuem qualquer representação, expressa ou implícita, referente ao conteúdo deste, sua qualidade, 
precisão, adequação para um objetivo específico ou comercialmente. Os autores, os revendedores e a 
Bookman Editora não tem qualquer responsabilidade relativa a perdas ou danos causados ou alegadamente 
causados pelo material, incluindo, mas não se limitando a, danos diretos, indiretos, incidentais ou decorrentes, 
perdas pessoais, lucros cessantes ou prejuízos resultantes de perda de dados, perda de serviço ou interrupção de 
negócio. Se a mídia estiver com defeito, você deve retorná-la para ser substituída. 


